El círculo proceso-persona

Leyendo esta entrada sobre la idea recurrente de que lo más importante para hacer software son las personas, me ha venido a la cabeza una reunión de hoy que hemos tenido en Biko. Las mejoras en el desarrollo de software no se acaban nunca, y cuando tienes a medio hacer algo (podeis echar un ojo al documento libre sobre la implantación de técnicas ágiles con CMMI) ya estás pensando en lo siguiente.
Como decía, el post referenciado, me recordaba lo que hacemos cuando intentamos mejorar las cosas. En la mente tienes que lo importante son las personas, pero lo más facil ¿qué es? ¡¡Definir procesos!! Te pones a pensar: si hacemos las cosas así, o de esta otra manera, y luego nos sale esta otra situación, entonces lo que hay que hacer es... definimos cómo se debe hacer esto, para que después se haga igual...

Así que nos hemos ido a los procesos y parecería que nuestra intención es implantar CMMI nivel 4 o 5. (uf, y por cierto, no os olvideis de la encuesta, gracia). Yo siempre acabo diciendo que lo mejor es usar el sentido común, conociendo bien las herramientas disponibles y con la experiencia, se pueden tomar decisiones acertadas que son totalmente diferentes en el marco de un proyecto u otro. Pero siempre parece que tiras a definir los procesos, más que a pensar que la gente que tenga que resolverlos ya sabrá hacerlos, o que precisamente, a los que no sepan les vas a formar.

Es una dialéctica complicada, la de procesos contra personas planteada en el manifiesto ágil. Y cuesta romper. Supongo que tenemos hecha la cabeza de una manera (dura) que es dificil de cambiar la forma de pensamiento.
Todo esto está relacionado con lo que ya he comentado en otras ocasiones: ¿buenas prácticas o procesos? Al final, depende de la gente, a unos los puedes matar de aburrimiento siguiendo procesos muy formales, y a otros perderlos por el camino si no les pones las luces de aterrizaje bien claras.

Encuesta sobre CMMI

A raiz de este post que menciona que hay 85 empresas más en España este año que han obtenido una certificación CMMI, me ha picado la curiosidad, yestoy montando una pequeña encuesta con intención de recoger información de aquellas personas que trabajen en una empresa con certificación CMMI. He reducido bastante el número de preguntas que quería hacer, para que no se haga pesada (que es lo que a mi me suele echar atrás para rellenarla, sobre todo, ;) si como en este caso no hay premio por hacerlo).

Si te apetece, aquí tienes el enlace: Encuesta sobre CMMI.

Y si conoceis a gente que pueda encajar en el perfil para rellenarla, por favor, me encantaría que les distribuyeseis el enlace.
Obviamente, después publicaré los datos y la información que pueda extraer de ellos en esta misma página. ¡GRACIAS!

Dos cosas

Ayer recogí del correo el libro de Andrés Perez sobre MarcaPersonal. Me hizo mucha ilusión ver mi dedicatoria escrita en papel "de verdad". Me imagino que será como volver a leer de nuevo su blog, que ahora estaba pensando, es uno de los primeros que sigo desde el tiempo que llevo leyendo blogs. !Gracias Andrés, eres un crack!
No deberíais dejar de echar un vistazo al blog de Andrés, sobre todo si ahora en época de crisis os encontrais dudando sobre vuestras opciones profesionales.

Por otro lado, otra conexión con el mundo real por el blog, me invitan !por fin! a escribir un post a cambio de dinero. :D Bueno, a cambio de una suscripción a GTDagenda, que la verdad, tiene buena pinta, pero de momento me quedo con lo que tengo, ya que necesitaría dedicar un rato que ahora no tengo para probar el sistema. Bastante tengo perfeccionando mi implementación de GTD... Si alguien lo usa sí que me gustaría conocer sus comentarios, a mi de momento RTM me funciona bastante bien, con su buena integración con GMail.

Organización del tiempo: GTD

Hace unas semanas, tras leer el famoso libro de David Allen "Getting Things Done" (también está en castellano), me decidí a poner en marcha mi aproximación al que parece uno de los mejores métodos de organización existentes a nada que consultes un poco en Google. En realidad, había leido el libro a principios de año, y lo volví a releer para empezar con el método.

Si no sabes de qué va GTD, brevemente te explicaré que trata de un sistema para la organización personal. Un sistema muy metódico, que tiene muchos seguidores por la red. No te voy a explicar aquí de que va, si no lo conoces, aparte del libro, te recomiendo este magnífico post de David Santo Orcero sobre GTD. Dice que es el primero, así que siguele la pista por que es una de las mejores explicaciones sobre una implementación concreta que puedes encontrar en castellano que no sea el libro mismo.
Mi aproximación no es tan completa todavía como la que puedes leer a David Santo, pero ahí vamos poco a poco.

Mis bandejas de entrada son el correo electrónico, y una bandeja tanto en la oficina como en casa. Utilizo rememberthemilk para gestionar mis listas, y me va muy bien la integración que tiene con GMail, ya que es el correo tanto personal como en el trabajo. Tengo mis listas (proyectos, acciones siguientes, en espera,...) organizadas por contexto con los tags de cada tarea, usando @xxxx cuando se trata de separar por trabajo, personal, telefono,... y les pongo +yyyy para indicar con qué persona está relacionada. Luego tengo creadas "SmartList" para las más usadas. El plugin de RTM además me relaciona las tareas con el correo electrónico desde el que las cree.
Estoy intentando rematar mis sistemas de ficheros, de momento me he organizado mejor las carpetas en los ordenadores, que no es poco, y veremos como voy haciendo las de papel, que en realidad son las que menos uso.

Suelo llevar una Moleskine encima cuando me acuerdo (y me cabe en algún bolsillo) para llevar notas, y que sirva también de bandeja de recopilación en cualquier parte. El problema que le veo precisamente es que necesito demasiado estar "online" para conocer todo el tema, creo que voy a empezar a imprimir las listas en mis revisiones semanales para poder llevarlas encima.

¿Funciona el método? Bueno, si eres un poco desorganizado por naturaleza: ¡pruebalo! Aunque únicamente apliques tres o cuatro cosas, seguro que te mejora la organización, y para mi, es un alivio ver que llevo el correo al día (¡¡llego a tener el INBOX vacio!!), y que sé que no se me escapa nada debido a un despiste.
Estos son un par de blogs sobre organización y productividad interesantes:

• El Canasto
  
• Habitos Vitales
• Semana Vista
  

Confianza Mutua, equipos y desarrollo

Uno de los posts que más visitas me ha traido, es en el que hablo sobre la confianza y las metodologías ágiles. Comentaba el porqué de que la confianza es básica para las metodologási ágiles. Ahora he encontrado un "post-it" que apunté hace tiempo, cuando leía un libro -lo malo es que no recuerdo cual, no sé si era uno de John Boyd o alguno sobre "Lean Software"- sobre que la clave de buen funcionamiento de un equipo es la confianza mutua, que basaba en cuatro pilares fundamentales:

• Visión compartida: Uno de los típicos problemas en un equipo de desarrollo es que cada uno va a su aire, y demasiado tarde se dan cuenta que van hacia ideas diferentes del producto o de su implementación. Para Scrum, por ejemplo, este es un punto muy importante que intenta reslver con la implicación de todas las personas afectadas en el royecto con reuniones periodicas, y con los desarrolladores en reuniones diarias.
• Comunicación: Una buena comunicación es fundamental para que puedas confiar que lo que entiendes te ha llegado de la manera adecuada y por tanto has entendido lo que la otra parte de verdad te ha intentado transmitir: que no es fácil.
• Toma de decisiones compartida: Obedecer ordenes predispone a la desconfianza de los datos con los que se ha tomado, o por qué se ha tomado. Que el conjunto del equipo asuma las decidiones que tienen que afrontar, implica que también asumen su responsabilidad, y que pueden confiar los unos en los otros, por que la decisión es de todos.
• Ética: No es sorprendente que un punto que pueda parecer que técnicamente no influye en una gestión de equipos, sea una clave fundamental para su buen funcionamiento. La falta de ética de uno de sus miembros corrompe cualquier atisbo de posterior confianza en esa persona, y por tanto, aumenta las suspicacias. No recuerdo ahora haber leido ningún libro sore metodologías ágiles que hablase explicitamente de este punto, pero cuando lo lei aquí, me parecio bastante básico y de sentido común. Una mala persona es capaz de envenenar cualquier equipo.

Y tú, ¿confías en los miembros de tu equipo? ¿confían ellos en ti? ¿crees que sois un equipo si esto no es así?

A la carga

Bueno, pues desde mi última entrada ayer... ah no! en Abril! hablaba sobre SpringSource, y ahora resutla que van a cambiar el modelo de licencias de Spring. Parece que no es tan fácil hacer dinero con el software libre.
Pero Andrés no me deja estarme quieto, y tiene toda la razón. Así que vuelvo tras los San Fermines, las vacaciones, la tranquilidad de Agosto y el agobio de trabajo de Septiembre. Tras el inicio del cole para mi hijo, mis primeros pasos en la implantación de GTD, varios libros leidos y releido y algún disgusto importante, pero superado. De estas y otras cosas espero volver a hablar con más asiduidad por aquí.
Hoy tenía planeado haber ido al evento "Por propia experiencia", al que habíamos enviado un trabajillo, sobre implantación de metodologías ágiles con CMMI. Podeis descargaros el documento y echarle un vistazo: Metodologías ágiles sobre CMMI. Tenemos mucho camino por hacer en este sentido, espero poder ir reflexionándolo por aquí. Ahora espero impaciente a leer los comentarios de Julen sobre el evento.

Escenarios ante "SpringSource Application Platform"

Tenemos una nueva plataforma de aplicaciones JAVA: SpringSource Application Platform. Es una plataforma que no cumple JEE completamente, y de hecho no parece que lo vayan a hacer. Soportan los módulos web como WAR, pero no se asoman los EJBs.
¿Necesitamos otra plataforma de aplicaciones en el mundo JAVA? Creo que no. El punto fuerte de esta nueva plataforma parece que va a ser la utilización de una plataforma OSGI. Esto puede ser un respaldo muy fuerte para esa arquitetura que no acaba de despegar en las aplicaciones reales. Pero tampoco es tan necesario, ni las ventajas que aporta son tan decisivas, nada que no se pueda hacer en el estandar JEE.
Como comenta Martín, esto podría ser un punto de inflexión en el mndo JAVA empresarial. Si se rompe la unidad sobre la plataforma JEE, podemos acabar con una de las ventajas más importantes: la interoperabilidad. Es cierto que ya hay muchas lineas de arquitecturas diferentes en JEE, pero la fuerza de Spring actualmente en muchos desarrollos pueden dar una fuerza muy importante a esta nueva plataforma.
De todas maneras, siempre es genial ver cómo hay gente que no se cansa nunca y tiene ideas novedosas y mejoras en un mundo en el que para algunos las cosas se han anquilosado demasiado. Y además, ahora ya tenemos un juguete nuevo para cacharrear :).

Patrones y mejores prácticas

Una de las ideas que me rondaba la cabeza hace tiempo es cómo aprendemos, y cómo enseñamos. Los últimos libros que he leido plantean estas cuestiones en base al concepto de patrones. Y me gusta. Patrones de cómo hacer las cosas en determinados contextos, proponiendo determinadas soluciones. También puedes aprender las tareas a realizar para resolver algo, si alguien te dice qué pasos debes dar, los aplicas y listo.
Lo situo un poco en la linea de procesos vs. personas de las metodologías ágiles. Si quieres que alguien aprenda gestión de proyectos (¡de equipos!-tengo que hablar un día sobre "Software for your head"), ¿le das los procesos que debe seguir? ¿o le explicas las situaciones, las posibles soluciones, los problemas,...? Si quieres establecer cómo se deben de hacer las cosas, puedes establecer procesos, o puedes explicar las cosas, su porqué y su cómo, pero ¿cuando hacer una cosa u otra?
Acabo de leer un artículo que me parece muy clarificador, desde mi punto de vista, que solo llevo menos de un año con responsabilidades de jefe de proyecto, para aprender a enseñar y enseñar: Better Best Practices.
Plantea la evolución de las "buenas prácticas" en una empresa apoyándose en el modelo de Dreyfus del Aprendizaje. Este se basa en poner cinco etapas al aprendizaje, dónde cada etapa tiene unas necesidades para realizar bien sus tareas y aprender con ello. Hay cinco niveles, resumidos más o menos:

• Novice - Needs to be told exactly what to do. Very little context to base decisions off of.
• Advanced beginner - Has more context for decisions, but still needs rigid guidelines to follow.
• Competent - Begins to question the reasoning behind the tasks, and can see longer term consequences.
• Proficient - Still relies on rules, but able to seperate what is most important.
• Expert - Works mainly on intuition, except in circumstances where problems occur.

La conclusión que he sacado después de leer el libro "Acerca de Internet" (que me compré por que ese artículo me picó la curiosidad), es que los procesos impiden la excelencia y la brillantez en los trabajos, pero que son necesarios para llegar a un nivel medio de desempeño, especialmente útiles en las fases de aprendizaje.
De aquí podemos llegamos a dos conclusiones de manera un poco más formal que creo ya he comentado otras veces, sobre las metodologías de desarrollo:

• Sobre las metodologías ágiles, que es dificil integrar a gente más "novata" en ellas. No hay procesos, y la gente sin experiencia necesita una guía más centrada en qué hacer. No se desenvuelven bien en entornos que aún no controlan.
• Sobre las metodologías basadas en procesos: Que impiden que la gente experta sobrepase el listón establecido de "media"(¿mediocridad?) en los procesos, y no sé aprovechan las experiencias completamente.
  

Testeo, cerdos y gallinas

¿El equipo de testeo de software -si existe :)- tiene una implicación como cerdos o como gallinas desde un enfoque ágil del desarrollo?
En las jornadas de la semana pasada JTS2008, se habla mucho de equipos independientes de testeo de software, de equipos separados que hacen el testeo y se comunican con desarrollo prácticamente para comunicarles los bugs. Entonces, ¿qué implicación tienen como equipo? Si no recuerdo mal, salvo la persona de Google (Julian Harty), nadie más habló de implicar gente de testeo con el equipo de desarrollo para ayudarles a mejorar su proceso de creación del software. Y esto me estuvo dando vueltas toda las jornadas.
Cualquier proceso de calidad que se precie tiende hacia la mejora continua, pero esto no creo que se deba entender en software como simplemente la eliminación de bugs de los producto, si no como la búsqueda de la eliminación de las causas de creación de bugs. El equipo de testeo puede ayudar identificando areas donde el desarrollo mete más la pata, detectar dónde es más necesaria formación, o un rediseño, o un mayor hincapie en las pruebas unitarias...
Así que lo veo complejo, por que empiezo a creer que es genial tener un equipo externo que haga testeo del software, en plan gallinas,... pero también creo que deben estar implicados como cerdos para la mejora continua "hasta el infinito y más allá!", y para eso necesitan plena involucración con el equipo de desarrollo.
Algunas pruebas típicas de testeo las estamos moviendo poco a poco hacia el equipo de desarrollo, como las pruebas unitarias, por que realmente... ¿que % de proyectos cuentan con un equipo de testeo? y las metodologías ágiles nos han dado las técnicas necesarias para ello (al menos las han popularizado). Este es uno de los puntos por los que mejoramos el proceso para eliminar la creación de bugs, pero queda mucho por hacer...

Usabilidad de los funcionarios

Biko2 ha publicado un informe sobre la usabilidad en webs de las Comunidades Autónomas. Podeis descargarlo en esta dirección de Biko2.

El equipo de consultoría y experiencia de usuario de Biko ha analizado los portales de las 17 Comunidades Autónomas españolas identificando aquellas que son punteras, presentando buenas prácticas e identificando los aspectos más críticos a mejorar.

Es un interesantísimo informe si te atrae el tema de la usabilidad o las administraciones públicas online. Lo que yo no sé es por qué nos preocupamos tanto por las situaciones online, cuando no sé si los de las ventanillas aprueban!
Veamos a la imagen típica de los funcionarios, tal y cómo es apreciada por multitud de nuevos aspirantes a un puesto "seguro para toda la vida", haciendo el paralelismos con lo que han aportado desde Biko2. :)
• Posicionamiento. "Como me posicione en la silla con plaza fija no muevo el culo de ahí ni para levantarme al café... bueno, eso sí."
• Servicios al ciudadano. "El ciudadano soy yo!"
• Ventana al visitante. "Siempre y cuando no vengan a verme a la hora del café!"
• Presencia Institucional. "Estaré presente siempre que venga el político de turno a llevarse las medallas"
• Factores motivadores. "¿motivación? ¿para qué?"

Sé de buena tinta que la gran parte de los funcionarios curran de verdad, y lo que me preocupa no son los que ya están en el sistema sin pegar sello, si no la imagen que tienen muchos jóvenes de que irse de funcionario es el chollo, pero no por las buenas condiciones de trabajo o su interés, si no por que ya lo tienes todo hecho e incluso puedes aprovecharte de ello-forzando la situación-.

Jornadas de testeo de software

El jueves estuve en el primer día de las jornadas sobre testeo de software JTS2008. La verdad que me han sorprendido la cantidad de conceptos que manejan en esta area, y que desconocía.
Hay varias cosas que tengo que analizar mejor. Me llama la atención que casi parece que son diferentes paralelos los procesos para la calidad mediante pruebas que la generada por los desarrolladores. Hablan de los testers por un lado, de sus pruebas, y no lo ligan demasiado a cómo eso afecta a los desarrolladores más que en que tienen que corregir los bugs que encuentran.
Y es curioso, por que yo tengo otro concepto más cíclico. Más que nada por que el concepto de fabricación con calidad, me resulta más atractivo que el de su control. Después de las pruebas, en algún momento se debería analizar lo que está pasando, para ver que se puede mejorar en el desarrollo que minimice en el siguiente ciclo de pruebas el número de errores.
Lo que sí coincido es que hace falta una persona (al menos) dedicada a diseñar/hacer pruebas de los sistemas en el equipo de un proyecto, y que no sea desarrollador.
¿Controlar la calidad, o fabricar con calidad? Yo que veo más cercano el equipo de desarrollo que el de testeo, me inclino a poner primero los medios en este primero para asegurar que hacemos software de calidad: lo que sea, pruebas unitarias, integraciones continuas, reuniones diarias, formación exhaustiva, mejores capturas de requerimientos, entregas iterativas,... y luego, pondría un equipo de test :)
Nos ha contado una persona de Google cómo tienen organizados los tests de sus apliciones: la palabra que más ha mencionado es "divertido". :) Curioso como cuenta que no tienen procesos establecidos, si no que cada uno es responsable de lo que hace y de cómo lo hace. Hay grupos de testeo en la empresa que apoyan a los creadores de productos, especializandose en las pruebas.

Anyway, bastante interesante la jornada, ya os daré más datos... o no,... :P os contaré más de la jornada del viernes, con más empresas contando sus experiencias. Idme contando, ¿teneis departamente de testeo de software?

Devolver el tiempo

Si hay una empresa que me guste ahora, esa es Atlassian. Buenos productos y una imagen envidiable en la red. Comparten sus ideas, y distribuyen sus productos con una licencia muy interesante para los usuarios.
Ahora acaban de publicar el "experimento" que van a realizar con sus ingenieros: "El 20% del tiempo". Y además van a blogear los resultados de sus experimentos, así que hay que seguir atentos. Este asunto trata de permitir dedicar a los desarrolladores el 20% de su tiempo en la dirección que elijan, de innovación, tecnologías o mejoras en los productos que soportan.
Me direis que esa es la famosa regla que Google aplica en su empresa, pero primero, tampoco dan tanta información, y segundo, tengo la impresión que es el 20% de 11 o 12 horas diarias de trabajo, no de una jornada normal. Atlassian reconoce que "copia" esa regla. :)
Dar esa confianza a los desarrolladores, puede significar sacar a flote grandes ideas que permanezcan escondidas tras la burocracia y las jerarquías. Supongo que se trata de recuperar, o no perder, la ventaja competitiva que tiene una "startup", a la vez que crecer de manera controlada.

A startup engineer must be all things - he (or she) is a full time software developer and a part-time product manager / customer support guru / internal systems maven.
As a company grows, an engineer spends more time doing the software development - but paradoxically he spends less time building the things he personally wants in the product.

Ahora le doy vueltas a cómo este tipo de resolución se puede aplicar a una empresa de servicios. Una empresa de servicios factura por horas, no hay un producto dónde se pueda producir un retorno de la inversión claro, ni donde centrar los esfuerzos personales-divergentes dedicados en ese 20% de tiempo. ¿Qué os parece? ¿cómo se podría trasladar este tipo de iniciativas a una empresa de servicios de software, que funciona por proyectos?

JIRA y CMMI

En nuestra empresa hemos implantando CMMI, acabamos de pasar un reluciente SCAMPI y pronto seremos nivel 2 oficialmente. Pero lo que ahora voy a hablar es del uso de JIRA como herramienta de gestión de proyectos. Quién conozca la herramienta y un poco de CMMI pensará que va ser un poco dificil conseguir que JIRA de soporte a algún tema de CMMI, si no que será más fácil usarla como herramienta PARA los desarrolladores, puesto que en realidad es una herramienta de "bugtracking".
Pero al final le hemos hecho algunos cambios, y JIRA nos va a dar soporte al EDT (Esquema de Descomposición de Tareas) para la fase de ejecución de proyectos. Cada incidencia creada en el sistema JIRA ahora podemos clasificarla en un tipo de Actividad (o Area de Conocimiento): Planificación, Desarrollo, Configuración, Sistemas, Implantación, etc,... Y con las versiones de JIRA podemos basarnos en desarrollo iterativo e incremental.
Esto nos da bastante flexibilidad tanto para desarrollar proyectos a precio cerrado, como para un día poder saltar a modelos más "ágiles" de desarrollo y comercialización.
Pero la gran mejora que podremos tener es obtener la verdadera visibilidad del desarrollo del proyecto, puesto que cada tarea puede ser reestimada en cualquier momento por cualquier persona implicada como responsable de sus tareas asignadas. Ahora tenemos que ir valorando la fecuencia de esas reestimaciones, la exactitud de las mismas dependiendo de la experiencia, y sobre todo, el impacto del cambio en la gente, que seguro será positivo.

Adopción ágil

Me envió Luis un enlace a una encuesta sobre la adopción de metodologías ágiles en las empresas.

Not aware	13%	26%
Not using	13%	16%
Investigating	14%	14%
Analysed and rejected	4%	3%
Pilot projects	8%	4%
Partial implementation (adoption of some agile practices)	17%	17%
Partial deployment (some projects are using this approach)	14%	12%
Deployed (all new projects are using this approach)	17%	8%

Fuente: www.methodsandtools.com

Según esta encuesta, obviamente han pasado dos años, el desconocimiento de las metodologías ágiles ha disminuido significativamente. Sin embargo de lo que no me fío, es de la fiabilidad de los ratios de adopción, parcial o completa, por que principalmente lo que decimos que es adopción de metodologías ágiles, no se trata más que de una aproximación a sus "buenas prácticas". Esta perfectamente explicado en este artículo de Version Cero: "Nosotros hacemos Scrum".
De todas maneras, si quereis más estadísticas:
Google Trends:

cmmi

agile

Esta última comparo CMMI y ágiles, por que la semana pasada pase mi primer SCAMPI en una empresa, y ha hablare de ello en otro próximo post.

Los grandes programadores

Hace unos años me regalaron (a mi y a Virginia, fue un regalo compartido de un jefe) un libro que leí con mucho interés. Ahora el autor del regalo, escribe sobre él en esta entrada del CES Digital:
Los maestros programadores.

El hoy arquitecto jefe de software de Microsoft, Ray Ozzie, se explayaba así: “los proyectos complejos de programación dirigidos por directores que no son programadores están frecuentemente condenados al fracaso, porque ellos no comprenden los intricados entresijos de los componentes del proyecto, ni las personalidades de los trabajadores. Los directores de proyectos de software han de comprender a las personas que trabajan para ellos. Yo conozco lo mejor que puedo la situación familiar, el estilo de vida y los hábitos de trabajo de cada una de las personas que trabajan conmigo. Sé que no podemos trabajar jornadas de nueve a cinco y sacar el proyecto adelante. También sé que no puedo presionar a la gente para que trabaje 24 horas durante todo el proyecto. Pero sé que, cuando llega el punto decisivo, puedo contar con ellos para trabajar día y noche si es necesario. Ahora, también tengo que saber cuándo hay que aflojar”.

No voy a sacar el recurrente tema de si los jefes de proyecto deben tener un perfil técnico o basta con un perfil de gestión. Lo que me interesa destacar son dos puntos:

• Hay que planificar los proyectos para que la gente los pueda hacer "de nueve a cinco", durante todo el proyecto. Ya vendrán problemas que no se te habían ocurrido. Seguro.
  
• Al tomar la responsabilidad de dirigir proyectos me he dado cuenta que esto no es realmente la informática. Dejas de enfrentarte a problemas matemático-lógicos, para enfrentarte (otras veces, afortunadamente, para colaborar) con las personas.

Ahora tengo encima de la mesa este artículo sobre "A scalable concurrent malloc implementation for FreeBSD". Un artículo que desde luego no tiene nada que ver con la gestión de proyectos, ni siquiera con la programación que hago actualmente. Pero es interesante.
La informática intenta resolver problemas de la gente, mejorar sus procesos, automatizar trabajos,... etc... pero los problemas realmente interesantes para un informático-programador son los que la propia informática genera a bajo nivel. Esos que nos empeñamos en dejar cada vez más abajo y dejarselos a los frikis de las universidades, o de las grandes empresas.
Ahora que busco desesperadamente mi marca personal, he pensado muchas veces en que los problemas que más me gusta resolver son los que no resuelven problemas de personas, si no problemas de computación. Aunque ya no tengo la experiencia necesaria.
Me gusta ser responsable de proyecto, decidir estrategias, implantaciones, tácticas, técnicas... enseñar todo lo que sé al equipo, hacer que trabajemos todos coordinados... pero... me gusta programar.
Si no podeis conseguir leer el libro Programers at Work, al menos leete el artículo de C. Urtasun.

Scrum y XP desde las trincheras castellanas

No puedo dejar de recomendar y agradecer la traducción que se han trabajado en Proyectalis del magnífico libro publicado en InfoQ Scrum and XP from the Trenches. Ahora tenemos este libro en un primer borrador traducido a castellano en: Scrum y Xp desde las trincheras .
Si eres de los que le da pereza leer en inglés, ya no tienes excusa.

El producto es el equipo!

He empezado a leer "Software for your Head" siguiendo la recomendación de Mario, y la verdad es que promete. Lo recomendó comparándolo con "Peopleware", así que tiene el listón muy alto.
Pero la idea básica que da en las primeras páginas, ya te lleva a reflexionar. Se plantean una investigación con equipos de desarrollo de software, y su estudio bajo esta sencilla premisa:

Equipos = Software

Y buscan los patrones que hacen funcionar a un buen equipo para desarrollar software de calidad y en plazos. Ahora bien, la primera idea interesante es cuando sben de nivel en la jerarquía. Ahora que soy responsable de proyectos, o eso que llaman mando intermedio también, he seguido pensando que mi trabajo es desarrollar software. Con más responsabilidad, más radio de acción, etc... pero que básicamente me encargo de desarrollar software con un equipo de personas.
Pero es por que no me he dado cuenta que ahora para mi, mi producto como resultado de mi trabajo, no es el software.

Mi producto es el equipo

Y plantearte eso te hace cambiar bastante algunos conceptos. El primero y más obvio, ¿qué narices sé yo de fabricar buenos equipos? El segundo un poco , un poco desasosegante... si hasta ahora lo que me gustaba es producir software... ¿qué hago yo aquí? Aunque, ¿puedo producir equipos que produzcan software si yo no sabría hacerlo? Juraría que no, y por ahí también intuyo que va el libro cuando habla de que el equipo debe tener las características que le pedimos al software que fabrica: estabilidad, escalabilidad, que no tenga/cometa errores,...
Otra idea me lleva a apoyar aún más con estos argumentos a las metodologías ágiles de desarrollo. "La persona sobre el proceso", ¿no implica el equipo sobre la gestión?.

Creo que me va a gustar mucho el libro, por que ya os digo que no he leido más de una pequeña introducción... y me ha dado mucho para pensar, aunque afortunadamente para vosotros, lo dejo para otros posts ;)

La chispa de la vida

Hoy hemos acabado discutiendo si los proyectos de software son como los de construcción o los de hacer tortillas de patatas (sic).
La gestión "clásica" de los proyectos (tipo CMMI, con toda la literatura que eso implica) con todas las técnicas y procesos de gestión de requerimientos, gestion de riesgos, planificaciones,... pueden ser usadas para todos los proyectos que creamos las personas. Pero un nivel 5 de CMMI no implica un éxito garantizado de los proyectos de software.
Tampoco la gestión ágil de los proyectos (XP, o SCRUM,...), como contraposición al modelo anterior garantiza que el desarrollo del proyecto vaya a ser un éxito. Tiene otro enfoque, ni mejor ni peor, depende de la ocasión y el contexto.
Sin duda Juan Palacio lo presentaba acertadamente como la tesis y la antítesis, de la que saldrá una síntesis en gestión de proyectos. Pero ¿puede existir algo que haga exitosos todos los proyectos software? Quizás demasiado complejo para implementarlo, pero ¿podría existir? Unos pasos previos que nos pongan en alerta ante cualquier fallo de software ANTES de que ocurra.
Un arquitecto sabe si se le va a caer el edificio o el puente antes de construirlo, le basta con simularlo. Pero no podemos simular un software, su simulación real requeriría la construcción del propio programa, con lo cual no lo simulamos, si no que lo probamos.
Un cocinero sabe qué queda despues de mezclar los huevos con las patatas, pero un desarrollador no puede estar seguro como va a ser la integración de dos componentes interactuando juntos, si tendrán problemas de integración, hasta que no los prueba.
En definitiva, que sabemos que no existe la "bala de plata", y que esta no va a existir. Esto hace mucho más divertido e interesante nuestro trabajo, o ¿no nos reiríamos más si de vez en cuando se cayese un puente o la tortilla de patatas no cuajase por más que la cociesemos?

Al final Oracle compra BEA, ¡y SUN mysql!

Pues al final la compró. Ahora solo hay que poner la cuenta atrás a ver cuando lo estropea :).
Y no sólo eso es interesante. SUN ha comprado mysql.
¿SUN puede hacer daño a Oracle con mysql en su mejor terreno, las bases de datos? Este movimiento me parece que puede tener mayor repercusión en el mercado que el de Oracle y BEA. Al final, Oracle volverá a cambiar de servidor de aplicaciones, lo que apostaría que echará a sus clientes más hartos, pero el mercado no cambiará demasiado.
Pero si SUN se plantea hacer frente a OracleDB con mysql, creo que estos se pueden poner algo nerviosos. ¿será casualidad que se comuniquen estas noticias el mismo día? SUN reforzará su mercado de software libre, e inyectará un buen capital para rematar algunos desarrollos que pueden hacer a mysql enfrentarse en grandes instalaciones a Oracle.

Me entero por Pensamientos.

El libro

Otra vez voy a hablar de un libro que no tiene nada que ver con el tema general de este blog-o lo que queda- pero que es muy cercano a mi.
Se trata de un libro titulado "El médico rural que tocaba a J.S.Bach", y lo ha escrito mi padre, Luis Carlos Díaz, sobre la vida de mi abuelo basándose en sus diarios. Vamos, más personal no puede ser.
No conocí a mi abuelo paterno, era médico rural en extremadura, y luego forense en San Sebastian-el juicio de Burgos le tocó, por ejemplo, como cuentan en el prólogo del libro-. Recuerdo cuando íbamos a San Martín de Trevejo (Extremadura) y todavía se usaba como mesa en la "boiga" una vieja tabla de madera que se usaba para los Rayos-X... ¡y la batería estaba en una esquina llena de telarañas! Ahora espero impaciente a hacerme con una copia del libro para conocer un poco más a mi abuelo.
Si os apetece leer algo diferente, os invito a acercaros a este libro. Podeis leer un pequeño resumen en una entrevista al autor. (Si quereis comprarlo, mejor poneros en contacto conmigo para obtenerlo directamente del autor ;) ).

Oracle a por BEA

Y no se trata de BEA la fea. Oracle va a intentar comprar BEA, ofreciendo un jugoso 25% de incremento sobre el valor actual de la acción. Ya hablabamos antes (mucho antes) de que Oracle necesitaba una posición más fuerte en el segmento de los middleware, y desde luego BEA es joya de la corona en ese segmento en mi opinión.

REDWOOD SHORES, Calif., Oct. 12, 2007—Oracle Corporation (NASDAQ: ORCL) today confirmed that it delivered a letter to the Board of Directors of BEA Systems, Inc. (NASDAQ: BEAS) on October 9 in which Oracle proposes to acquire BEA for $17.00 per share in cash. The $17.00 per share offer is a 25% premium over yesterday's closing price of $13.62.

Con semejante adquisición (aparte de que los desarrolladores de Oracle deberán otra vez liarse la manta a la cabeza y aprender nuevas tecnologías adquiridas) Oracle podrá hacer frente a las amenazas de Microsoft, SAP y RedHat/JBoss.
Para "variar", Oracle prefiere comprar la innovación o la tecnología a crearla -afortunadamente para ellos viendo como hacen algunas cosas :)-. Y este movimiento puede dar una ventaja muy importante a Oracle en los entornos empresariales de gran tamaño, el mismo suministrador con un middleware decente, y una base de datos consolidada.
Supongo que ahora estará en manos de los accionistas el vender la empresa, pero si yo fuese cliente de BEA la verdad que sabría si este movimiento me perjudicaría o favorecería. Veremos qué da de sí esta noticia.

Actualización: Parece que BEA ha rechazado la oferta. Una opinión interesante de alguien que dice ser empleado de BEA.

Lockpicking

Hace un tiempo escribí un post describiendo un simil que se me había ocurrido entre el software libre y el conocimiento de cerrajería [Cerrajeros y seguridad], y me he sonreido al leer un foro donde los propios cerrajeros se plantean la misma cuestión de libertades pero asociada a su profesión, así que aquí les hago trackback-back-again: Lockpicking Sport. Echadle un vistazo, es curioso ver otro punto de vista, no sé si extrapolable o no, pero curioso.
Un saludo a todos los cerrajeros :)

Free Burma!

Estrategia Open-source: No lo sé

What is the business model for this? (for Open-source)

What's the business model? I don't know. But if you don't have adoption, it won't matter what business model you use. Companies that sell open source are prioritizing community and adoption over instant monetization. We will win.

Q&A: Jonathan Schwartz on Sun's open-source business strategy

El oráculo

¿Habeis visto últimamente Oracle.ES? Así empieza su nuevo mensaje :)

Estimados visitantes:

En primer lugar presentarme, soy P.P.G. , actual propietario del dominio ORACLE.es , y escribo para informarles personalmente y como es justo del estado de la página, que había estado usando con referencia a los oráculos antes de este escrito, y 6 meses después de mi registro me van a quitar para dársela a Oracle Iberica SL.

Hay que ser muy muy [?] para que se "te olvide" un dominio de semejante importancia. Pero bueno, estas cosas pasan... y yo sin enterarme.

Tus series favoritas de médicos y su "código fuente"

De vez en cuando la "inspiración" viene de sitios insospechados. Esto he recibido por email hoy mismo, de un aficionado al ajedrez.

¿Por qué en las series como 'Hospital Central', 'Anatomía de Grey' o 'House' el que más sabe de medicina, aunque sea el director del Hospital, el que más cobra, está a pie de mesa de quirófano o visitando pacientes y, en cambio, en el desarrollo de software el que tiene más responsabilidad no ve ni una línea de código, ni igual un mapa de la arquitectura de la aplicación.

Quizás leo demasiados blogs...

Puede ser que tenga en mi cuenta de Bloglines demasiados "feeds"(105), pero cada vez que me interesa un tema, "casualmente" veo referencias a comentarios en blogs que lo tratan.
Lo que sospecho es que siempre leo entradas sobre cientos de temas diferentes, y dada la amplitud y selección de temáticas a los que estoy suscrito, siempre al focalizar mi mente en algún tema en concreto durante un tiempo, "aparecen" posts sobre ese tema. Aunque claro, no es que aparezcan y me interesen, si no que me interesa el tema y entonces los marco como interesantes.
Si estoy mirando cómo vender lo "ágil" o entrevistar a futuros candidatos, Juan Palacio hablará sobre ello. Si quiero averigüar como reorientar mi carrera, Andrés Perez comentará siempre algo interesante para mi marca. Si me harto de tanta bienaventuranza webdoscera, Rogelio tendrá un comentario irónico que me reconciliará con la red. Y si estoy poco inspirado en mi vida, Telémaco soltará algun post genial que me de una buena idea. Y así podría seguir con mis otros 100 blogs...

Ahora tengo un problema, no sé que va antes, si mi pensamiento, o el de la blogsfera... :)

¿Vende "Lo Agil"?

Vender proyectos sin asignar un presupuesto cerrado al inicio es dificil... ¿o imposible? Vale, sé que Juan Palacio los hace, pero ¿quién vende proyectos sin ir contra presupuesto cerrado? La confianza necesaria para ello con un cliente no nace de la "fama" que pueda tener la empresa o el equipo, si no solo posiblemente tras una relación larga de éxitos.
Mi duda, que planteaba también hace cinco minutos en este interesante post de Rodrigo Corral, es cómo encajar una metodología ágil dentro de proyectos con requerimientos y presupuesto cerrados en la primera fase. Obviamente, rompe dos esquemas importantes del manifiesto ágil:

Customer collaboration over contract negotiation
Responding to change over following a plan

Las buenas prácticas de las implemenaciones de las metodologías ágiles están aquí para quedarse y son de gran ayuda, pero rompiendo dos de las cuatro frases objetivo del manifiesto... ¿usarás una metodología ágil?

Infraestructura web JAVA

¿Qué harías si sabes que cualquier cosa (herramienta, framework,...) que elijas sabes que la vas a tener que cambiar en unos años? Pues prepararte para el cambio: buscándolo.
El montaje que hemos realizado para los desarrollos JAVA sigue la clásica configuración de tres capas: presentación, servicios y persistencia, intentando no atarnos a ninguna tecnología demasiado de la que nos sea imposible prencindir en un momento dado.
La elección de las tecnologías depende de muchos factores que no son solo tecnológicos, como el conocimiento con el que puedes contar en la organización para empezar a trabajar, o la disponibilidad de personas formadas para una posible contratación. Después ver que eficacia y eficiencia puedes esperar de ellas.

• Presentación: Necesitas un framework ágil, en el que se pueda ser eficiente y rápido desarrollando la interfaz. Ese framework no es Struts 1.X., ¿podrá ser Struts 2, o Wicket? Hay muchas opciones en esta capa. Ahora hemos elegido Struts 1.x... jeje, sí, ese que no es ágil y es pesado de desarrollar (muchos xml, clases), por que era donde teníamos mayor conocimiento y experiencia.
• Servicios: Al decidir seguir una arquitectura basada en servicios, debes decidir también como va a ser el acceso a los mismos: EJBs, clases locales, servicios web... La opción que parece que ofrece más flexibilidad es Spring. Permite la utilización de IoC de manera que nos facilita el acceso a los servicios inyectándolos en la capa de presentación, y además tiene utilidades para hacer transparente el cambio de EJBs a clases o viceversa.
  
• Persistencia: Para proyectos que no requieren de excesivo énfasis en el rendimiento, un framework de persistencia objeto-relacional parece hoy en día la opción más interesante. Aquí vamos con Hibernate.

Spring es una pieza muy importante en esta arquitectura que estamos implementado. Es un poco el pegamento entre las capas, y además ofrece muchas prestaciones interesantes: gestión de transacciones, aspectos, soporte de pruebas unitarias,...
La evolución de esta arquitectura está clara:

• Migración de Struts 1.x a otro framework, que sea más ágil, ofrezca una velocidad de desarrollo mayor y basado en plantillas que la gente de diseño pueda tocar más fácilmente. Wicket parece una gran opción.
• Eliminación del trabajo manual de modelado de la persistencia. Hibernate Annotations simplifica el trabajo de mantenimiento de la persistencia, pero la automatización del proceso es un objetivo más ambicioso. Estuve probando androMDA, pero la verdad que no lo hice funcionar satisfactoriamente.
• Despliegue automático de las aplicaciones en versiones EJBs o clases locales o servicios web. Una vez que se tiene las clases de implementación de los servicios, un objetivo sería poder desplegar los mismos de manera automática en cualquier plataforma.
  

¿Qué más ideas se os ocurren? Obviamente hay mucho más que hablar sobre arquitectura, estais invitados. :)

Camino sin Destino

Al final llegué a la conclusión que con mi cambio de hace unos meses no acerté. El trabajo que estaba desarrollando no me resultó demasiado interesante, y las ventajas que tenía no han podido convencerme.
Así que justo cuando ya me planteé en serio el hecho de cambiar de trabajo me llamó un amigo que necesitaban un jefe de proyecto, para una oficina que van a abrir hemos abierto en San Sebastian. Casualidades de la vida, así que ahora que voy descubriendo, o intentando convencerme, de que lo bueno no es el Destino si no el camino que te lleva a él, me embarco en mi sexta aventura profesional. Con muchas ganas, por que es el tipo de trabajo que quizás llevaba buscando algún tiempo. Intentaré hablar algo más sobre él.
Llevaba algo más de tres meses sin escribir por aquí. Pero nos os he dejado de leer...

Empresas piramidales

Al de arriba le pinchan, canta la canción... y todos intentan hacerle el coro.

Esta es la manera de los que tienen miedo.
Esto debe ser el efecto de la fiebre. Quizás necesite otro chute de Nolotil.

Bissines Intelligence - Open Source

Hace tiempo que les había prometido en un comentario que les iba a dedicar un post a este blog tan interesante de TodoBI. Aquí ya sospechamos ;) que en un futuro solo quedará el software libre, y en el campo de Bussines Intelligence en Stratebi lo plantean realmente bien. Cuatro packs para el acercamiento a sus soluciones, de manera gradual y según las necesidades.
Ahora han preparado un curso preparado especialmente para la gente que quiera iniciarse en este mundo e iniciar su carrera profesional en esa linea. El precio me parece bastante ajustado, así que si os interesa el tema, no dudeis en echarle un vistazo.

Especialmente dirigido a recién licenciados, a punto de concluir o con reciente experiencia profesional !!

Queremos crear un gran equipo!!

Este curso es el primer paso para que podáis desarrollar vuestra carrera en el mundo del Business Intelligence con tecnología Java Open Source y Stratebi os ofrece grandes oportunidades para comenzar.

Publicidad "contextual" en videos

Acabo de ver el video sobre el N95 de Nokia en El Mundo, y no sé como establecen la publicidad que meten al inicio, pero me han puesto publicidad del Tomate Orlando. Vamos, que muy contextualizada no me ha parecido.
Espero que las campañas de publicidad que se ciernen sobre nosotros en los videos sean un poco más refinadas.

Cita de masas

Este es el mayor peligro que hoy amenaza la civilización: la estatificación de la vida, el intervencionismo del estado, la absorción de toda espontaneidad social por parte del Estado; es decir, la anulación de la espontaneidad histórica, que en definitiva sostiene, nutre y empuja los destinos humanos. Cuando la masa siente alguna desventura o, simplemente, algún fuerte apetito, es para ella esa permanente y segura posibilidad de conseguir todo -sin esfuerzo, lucha, duda, ni riesgo- sin más que tocar el resorte y hacer funcionar la portentosa máquina. La masa se dice: "El Estado soy yo", lo cual es un perfecto error. El Estado es la masa sólo en el sentido en que puede decirse de dos hombres que son idénticos, por que ninguno se llama Juan. Estado contemporaneo y masa coinciden sólo en ser anónimos. Pero el caso es que el hombre-masa cree, en efecto, que él es el Estado, y tenderá cada vez más a hacerlo funcionar con cualquier pretexto, a aplastar con él toda la minoría creadora que lo perturbe -que lo perturbe en cualquier orden: en política, en ideas en industria.

Jose Ortega y Gasset
La Rebelión de las masas

Este es uno de mis libros de mesilla favoritos. Y perdón por la pedantería.

Firebug: Desarrollo Web Evolucionado

No suelo dedicarme a relatar herramientas, pero ésta merece el post: FireBug ha visto la luz en la versión 1.0. Una herramienta indispensable para cualquiera que haga desarrollo web, con numerosas utilidades que nos facilitan la vida para pegarnos con JavaScript, CSSs y HTML.

Si todavía no la habeis probado, os la recomiendo encarecidamente. Eso sí, únicamente para FireFox, ¿o acaso utilizais otro navegador? :)

Conclusión inteligente

No tiene desperdicio la tira de Dilbert de hoy.

- Jefe: (a la secretaria) Carol, prepara una reunión de la plantilla.
- ¿sobre qué tema?
- Planeo fusionar 6-sigma con las metodologías ágiles para eliminar la diferencia entre nuestra estrategia y nuestros objetivos.
- Vale, simplemente diré: "Pérdida de tiempo"

¿cuantos jefes son "valorados" de esa manera? ¿se lo habrán ganado a pulso, como el de Dilbert?

No tiene precio

Me voy de rebajas:

comprar unos zapatos Clarks,... 65€
regalar una cazadora,... 120€

movil nuevo, descuentos del 50% en las llamadas,... !no tiene precio¡

La campaña de Euskaltel da un poco de pena, no pareces buen vasco si no te quedas con nosotros, en casa, viene a decir. Genial argumento para una compañía de telecomunicaciones. ¿y por qué no me haceis mejores precios por ser vasco? N.T.J.
Así que me voy a Orange, que no creo que sean mejor compañía, pero por lo menos esta vez se lo han ganado haciendo la mejor oferta.

PD: Para los que no seais del País Vasco esta polémica de Euskaltel-Orange no os toca ni de refilón, pero la verdad que está haciendo correr ríos de tinta (electrónica).

Dos añicos, dos...

...son los que ya tiene este blog.
El año pasado ni siquiera puse un post conmemorativo de su primera onomástica, pero esta vez me apetecía reseñarlo. Al principio hablaba sobre todo de software libre, ahora de vez en cuando escribo sobre temas de metodologías también, y ultimamente escribo poco :). Pero espero que vaya a más.
Algunas de las búsquedas más raras, me encuentran...

• intentando abrir una puerta en la que se han dejado las llaves puestas por dentro (aquí),
• o intentado hacer helado (aquí).
  

Todo empezó hace dos añitos, con un sosete primer post. En Febrero de 2004 colgué en la red mi trabajo sobre nuevos modelos de negocio de soft. libre, que ha sido descargado unas miles de veces desde entonces, e iba contando cosas aquí sobre él. En Julio de 2005 este blog fue añadido a Planeta Código, una creación de Juanjo Navarro (¡gracias!), una comunidad de blogs sobre programación, y este hecho fue sin duda el que más lectores le ha proporcionado a Najaraba. En Noviembre de 2005, gracias al trabajo sobre nuevos modelos de negocio sobre soft. libre y este blog, me invitaron a una charla en Mallorca sobre software libre. Este año 2006 que termina no ha sido tan interesante en estos aspectos, la verdad que desde que nacio el "peque" le dedico menos tiempo, y sigo casi un centenar de blogs, de los que no doy abasto para llevar al día todos sus post: algunos que hoy son referencia de la blogsfera, los hemos ido viendo crecer en estos dos años, mientras otros nos hemos quedado más modestos ;)

También hubo un intento en el 2005 de poner en marcha otro blog, también idea de Juanjo, sobre niños: Locos Bajitos, pero lo fui abandonando. Ahí queda Juanjo escribiendo un post de vez en cuando.

Más personalmente, este año he cambiado de casa, y otra vez de trabajo. Voy por "mi" quinta empresa (eresMas, Reuters DSS, Editorial Aranzadi, Indaba y ahora IZFE) desde que empecé a trabajar en el año 2000 y me imagino que no será la última. Aunque me parece que el año que viene va a ser mucho más tranquilo, a no ser que me lie la manta a la cabeza y por fin me decida a instalarme por mi cuenta (se admiten sugerencias ;). Por cierto, aquella serie con la que empecé a escribir sobre como convertir las ideas en software (2, 3, 4, 5, 6, 7, 8) se quedó en "código mojado", pero quién sabe...

En definitiva, que el barrio me gusta, y no me cambio, me quedo por aquí otro añito más.

La confianza y las metodologías ágiles

Llevaba varios días dándole vueltas a una idea, que acabo de plasmar en un corto comentario en este interesante post sobre los " 7 paradigmas para ser ágiles". Es algo tan sencillo como que para moverse hacia las metodologías ágiles en una empresa, la idea fundamental es la C-O-N-F-I-A-N-Z-A. Confianza .
Al abandonar paulatinamente el control basado en procesos, empiezas a confiar en que las personas desarrollarán su trabajo de la manera adecuada por que saben hacerlo y quieren hacerlo. Esto tiene numerosas implicaciones. De repente el departamento de calidad no tiene que vigilar el obligado cumplimiento de normas, procesos y burocracia. Los jefes deben confiar en sus empleados (no me gusta decir "la empresa debe...". La empresa no confía, la empresa no siente ni padece). Los empleados y jefes deben confiar en sus compañeros.Confianza en los conocimientos de los empleados, en su sabiduría y buen hacer. Confianza en la palabra de las personas. No necesitas poner exhaustivamente todo por escrito. Confías en ellos, si te dicen algo, lo harán.
Pasar a un modelo colaborativo exige confiar. Cuando en una organización se han creado los procesos para controlar el trabajo, es dificil volver atrás. Pero no debe ser imposible.
Por algo Joel Spolsky dice que hay que contratar a los mejores, únicamente en las personas en las que estés convencido.

In principle, it’s simple. You’re looking for people who are

1. Smart, and
2. Get things done.

That’s it. That’s all you’re looking for.

Así puedes confiar en ellos.
Sin duda no es un paso fácil en muchas empresas.

• Existen subcontrataciones que se controlan exageradamente por que "vete tú a saber qué hacen". Pero entonces ¿por qué se les contrato? ¿se confiaba en ellas? O quizás se ha perdido la confianza a lo largo del proyecto. Entonces el problema no es controlarlas, si no volver a confiar en ellas, analizar qué se hizo mal.
• O a veces hay jefes de equipo que controlan al milímetro lo que hacen sus subordinados, cargándose un exceso de trabajo que no les corresponde, y siendo un cuello de botella en el proyecto.
• Incluso cuando los trabajadores no se fían del trabajo de los demás, o lo desprecian si lo han hecho en otro equipo, se ponen zancadillas al buen desarrollo de los proyectos.

¿Se puede corregir esto con normas y procesos? Pues quizás a veces sí. Pero, si queremos movernos hacia las metodologías ágiles, por que creemos que pueden ser beneficiosas en un buen número de proyectos, centrándonos más en las personas que en los procesos, el objetivo debe ser recuperar la confianza.

Actualización, para los que no soleis leer los comentarios (!¿por qué nooo?!) :)
escéptico comenta:

1.- Un Jefe de Proyecto debe ser paranoico respecto a los procesos ("Las cosas pueden fallar") pero confiado respecto a las personas ("Mi equipo saldrá adelante").
Por desgracia a veces ocurre lo contrario: se desconfía de las personas pero aun así se mantienen planificaciones irreales.
2.- Realmente los que saben realizar el trabajo son los miembros del equipo. El Jefe de Proyecto se dedica a coordinar los esfuerzos, no a repasar, revisar lo que se hace.
Por desgracia hay Jefes de Proyecto que piensan que si se pudiesen clonar ellos mismos y reemplazar a su equipo, las cosas irían mucho mejor.
3.- Un Jefe de Proyecto está solo en cuanto a sus temores pero debe escuchar y prever los de su equipo.
Por desgracia hay Jefes de Proyecto que desaniman a su equipo con su actitud.
4.- Un Jefe de Proyecto debe defender a su equipo ante su Supervisor y filtrar los aspectos negativos de éste a sus colaboradores.
Por desgracia muchos Jefes de Proyecto se quejan de los malos mimbres que les han proporcionado y hacen de mera correa de transmisión de la presión ejercida desde arriba.

2ª Actualización: Para los futboleros, Oscar me hace notar que la confianza es importante en cualquier campo (¡hasta de fútbol!): La confianza y las caderas ágiles.

La publicidad de Microsoft sobre ¿software libre?

Lleva unos días saliendo este anuncio en mi bitácora, sobre Software Libre (también lo he visto creo que en Meneame alguna vez):

Y un día por curiosidad descubrí... !que se trata de un anuncio de Microsoft! Y te lleva aquí: http://www.microsoft.com/spain/hechos/default.mspx, donde te cuentan alguna historieta sobre una tal teleflora.

Ojalá estas maniobras, de "información" y competencia fuesen las únicas que utilizasen, y no la intimidación y el juego sucio del que han hecho gala hasta ahora.

Relacionado: Vivir del software libre

Bruce Lee hasta en los punteros

Vía messenger, de vía email, de vía vete-tu-a-saber... Si eres programador, te toca el punterito que todos llevamos dentro.

Empty your memory,
with a free()...
like a pointer!
If you cast a pointer to a integer,
it becomes the integer,
if you cast a pointer to a struct,
it becomes the struct...

The pointer can crash...,
and can Overflow...

Be a pointer my friend...

Esta versión me ha gustado mucho... ¿cuantas más conoceis?

Un añito

Y es que con esa carita no me he podido resistir a ponerle aquí.

Por qué los programadores se llevan el trozo grande del pastel (sic)

Dice Joel Spolsky que hay que saber ser flexible para cambiar de contexto cuando sea necesario. Critica que en un desarrollo de un proyecto con una metodología ágil, no se fuese capaz de cambiar al programador para algo quizás más importante por no perder un día de éste en ese proyecto. Lo que parece en realidad es falta de comunicación o conocimiento, ¿qué era más importante para la empresa en ese momento? O el desarrollo del nuevo producto, o la atención al problema que ha surgido sin planearlo. Alguien tenía que decidir. En realidad creo que la crítica a las metodologías ágiles en este caso no está bien traida, pues en realidad como afirma al final el problema es del "manager"

But every decision has pros and cons and when I hear a manager who is just talking about the cons without considering the pros, that manager is not doing their job.

Sim embargo lo que más me ha llamado la atención es esta frase:

This Is Why Programmers Get The Big Bucks. The whole reason you gave them Aeron chairs, unlimited M&Ms, free catered lunches, and the kickass computers with the 30" LCDs is so they can deal with new bugs Microsoft introduced in their code by messing up a DLL that used to work.

No cabe duda de que Joel Spolsky sabe cuidar a sus trabajadores, M&Ms ilimitados :) , comidas incluidas, los mejores ordenadores... y lo que de verdad importa, una valoración excepcional del trabajo que realizan sus programadores. Sabe que su trabajo no es fácil, y lo valora. No es el primer comentario en el que Joel da muestras de saber tratar a sus empleados.
Vamos, como aquí por España, lo mismo. ¿alguién quiere seguir siendo programador toda su vida?

Arte e informática

Hoy hablando con un compañero de trabajo, al que me he enterado que le gusta el diseño y las artes plásticas (echad un vistazo a su trabajo, muy interesante), he llegado a una exposición de arte que se realizó hace un año en la Facultad de Informática de San Sebastian: El Bosque Virtual. Una curiosa iniciativa. Para los que hemos pasado por ese insulso edificio es toda una alegría ver el hall de la FISS de esa guisa.
Arte e informática unidas.
Espero enterarme por adelantado si se repite otro año :)

PHP on Rails: Code Igniter

Cuando me he puesto a hacer aplicaciones en PHP echaba de menos mis controladores, filtros, vistas y cada cosa en su sitio de Struts en la plataforma J2EE. Luego vi como Rails implementaba el MVC de una manera elegante y sencilla. y ahora he descubierto Code Igniter para PHP. Por lo que he visto es algo así como el framework MVC de Rails, pero para PHP.
Code Igniter es un framework sencillo, que no te obliga a aprender apenas ningún tipo de sintaxis para configuración ni templates. Separas fácilmente los controladores de la vista, y el soporte para el Modelo que te propone es ya opción tuya para usarlo. La configuración es un sencillo fichero en PHP.
Una interesante plataforma para PHP. ¿hay alguién por ahí que todavía no use el patrón MVC? :)

Nuevo ordenador "portatil" de Sun

Impresionante cacharro para colocar en el jardín o la terraza de tu casa. Se trata del proyecto Blackbox. Una pequeña caja para un gran ordenador :)
Como si de un container se tratase, solo debes enchufarlo y todo listo. Eso sí, me imagino que un buen canuto necesitará.

Se trata de un soporte preparado para un gran ordenador, de manera ampliable, que puede ser depositado en cualquier sitio.









Me pregunto cuantos de estos necesitaría Google para establecerse en nuevos territorios...

Vivir del software ¿libre?

Hace ya días que quería apuntar a una interesante discusión producida en Vivir del Software (BTW, muy interesante el blog), concretamente en ¿software libre?. Una discusión muy interesante, más cercana a la realidad empresarial que lo que a veces comentamos los que únicamente somos teóricos en esto del software libre y negocios, sin experiencia real viviendo de ello, lo admito, por supuesto :).
Por otro lado, he encontrado este documento sobre "Decisiones Inteligentes" de un "Microsoft Student Ambassador" (?), en el que compara un poco las plataformas libres y comerciales...

Con el software propietario las licencias son más claras en lo que ofrecen y lo que cubren, así como las indemnizaciones en términos de violaciones de propiedad intelectual y derechos de autor para cada producto en particular.

¿de verdad? Será que son más claras en no asumir ninguna responsabilidad, o en decir que te pueden devolver el dinero de la licencia , no más.

Lo que la licencia Open Source normalmente permite es que cualquier persona pueda pegar componentes al kernel o a una distribución, lo cual genera que dichas distribuciones estén en continuo cambio; por lo tanto, una versión de sistema operativo que esté disponible para descargar desde Internet tiene alta posibilidad de ser diferente día a día, dependiendo de qué tanto cambien los componentes o el mismo kernel. Así entonces, una versión de Linux comercial que se haya entregado a la comunidad puede cambiar en cuestión de días sin el control de la empresa que la produjo.

Bueno, puede ser cambiada !eso es lo mejor del open Source¡ Pero a ver, si tú quieres una versión de un distribuidor, no vas aleatoriamente a buscar por Internet qué bajar. Tal y como se cuenta parece que no sabes lo que descargas... pero eso ya depende únicamente de las fuentes... ¿te comprarías un Rolex en el chino?

para poder garantizar el respaldo y la operación correcta de los componentes, las compañías están obligados a utilizar la distribución y versión específica que el proveedor ha dispuesto ya que si no lo hacen de esa manera, ellos no van a garantizar ni soportar el sistema resultante. ¿Sigue siendo esto Open Source? Esto ya no encaja en la filosofía del software libre ya que realmente no existe tal libertad de usar lo que yo quiera sin perder lo que supuestamente adquirí al pagar por tener las distribuciones de estos fabricantes.

En cierto sentido a mi también me extrañó esas clausulas al conocerlas por primera vez, pero hay que darse cuenta de que tienes dos cosas: soporte sobre la distribución para la que lo has comprado, o posibilidad de aplicar tus parches en el momento que quieras. Es decir, soporte para la versión como con software comercial, pero además posibilidad de hacer cambios.

El documento tiene unas cuantas partes más que rebatir, pero será otro día (que estoy en el curro ;) ). Si os lo llegais a leer, podéis comentarlo aquí. Animaos!

Hacer helados es como crear software

He comprado una barra de helado de corte. Con sus correspondientes galleticas, de la misma marca. Así que después de cenar, ¡a por el postre!
¿cómo es posible que la medida de las galletas no sea igual a la del corte del helado? Ahh!! ¿quién tomo la decisión del tamaño de la barra? Seguramente no la misma persona que decidio el tamaño de las galletas. Pero es que el tamaño no es ni proporcional, las galletas son cuadradas y el corte rectangular.
¿dónde se fraguo semejante error? ¿en la etapa de diseño? ¿no había comunicación entre los equipos de las galletas y el helado? ¿quizás rencillas personales que impedían la correcta comunicación? ¿o hubo un error en la fabricación de las galletas? ¿no seguían la ISO-4329993?
Pero lo peor... ¿es que no hacen test unitarios? Mide las galletas, mide el helado... ¡¡pero ponlos  juntos y observa que sobra galleta o falta helado!! :)

PD: No sé a cuento de qué viene esta chorrada, pero el helado estaba bastante bueno.
PD. Seguro que alguién me da la explicación real de por qué esa diferencia de tamaños :) Todo se sabe en la blogesfera.

Web 2.0: El poder para las empresas. O'Reilly en Vitoria

Tim O'Reilly ha dado una conferencia en Vitoria. Entretenida. Interesante, pero tampoco nada novedoso.
Empezó hablando un poco de su editorial, que siempre viene bien un poco de marketing viral... ¿o es publicidad? :) Una función importante de su editorial es identificar los patrones que marcan el futuro de la tecnología. Descubrir lo nuevo. Ahora viene un resumen, así que si ya estás en el mundillo no te aportará mucho.

Presentó al movimiento Open Source como paradigma de la cooperación, y dijo que ese movimiento se ha llevado desde el software a la web, donde ya el hardware se ha convertido en "commodity", el software como producto lo está haciendo, y ahora son los servicios (¿propietarios?) los que van a pasar a tener importancia en el mercado.

Por tanto, la noción importante ahora es el SaaS (Software as a Service). En la web 2.0, que no son más que servicios donde los usuarios crean el contenido del que pueden disfrutar el resto de usuarios encontramos una serie de características:

• Los usuarios añaden valor al servicio ofrecido. Por tanto, las empresas deben sacar valor de cualquier participación del usuario e invitar a este a que participe continuamente.
• El valor de compartir en red debe ser activado por defecto. La primera propuesta al usuario es que comparta todo con todos, no solo con sus amigos o grupos. Así se agregará más valor al servicio.
• ¿por que el "Beta"? Por que lo servicios están en continuo desarrollo aprendiendo de sus usuarios.
• "Data is the 'Intel inside'". Esto tiene muchas implicaciones, se refiere a que ahora los datos son el producto indispensabel. Los usuarios los creen, los mantienes y los utilizan... ¿pero quién los guarda, los posee? :S

En definitiva, ahora los servicios son la nueva plataforma. Y los datos el producto.
En el turno de preguntas, en el que Tim no se mojo mucho sobre el futuro, me interesaron dos preguntas especialmente. Sobre la web semántica, Tim dijo que la ve como lago muy teórico, con mucho formalismo y todavía complicado de usar. No ve aplicaciones sencillas, que consigan enganchar al usuario. Esto creo que es cierto, falta esa "killer application" que mueva sobre sí misma todos los esfuerzos en la web semántica.
Y otra pregunta se le planteo dando por supuesto que l os usuarios tienen el poder en este tipo de aplicaciones,... pero Tim le dio la vuelta y dijo que a quien le da el poder realmente es a las empresas. Las empresas disponen de los datos, los explotan. Bueno, sin duda es un punto importante, ¿pero a qué tipo de poder nos referimos aquí? Es dificil que los usuarios puedan explotar todas las posibilidades de los datos en su conjunto, en toda su profundidad. Y también los datos de los usuarios dependen de la "benevolencia" de la empresa en su utilización y explotación. En ese sentido las empresas de web 2.0 tienen la sartén por el mango.

Y así fue, después había un lunch, en el que en el camino a la la puerta me comí tres pintxicos, pero me fui rápido a ver si veía a mi hijo antes de dormir. Así que no hice mucha función de "networking", que es de lo que se trata en estos saraos, ¿no? :)

Más impresiones sobre la conferencia: (vía Technorati):

• Enrique Aguilera
• Domoku
• Paradise City

Actualización: El mp3 para descargar está disponible en EuskaDigital (Gracias, Rafa).

Mi movil ya no es naranja

O sigue siendo, pero me parece que ha cambiado de tono. Enchufo el movil, y me indica: "Orange". Algún rato me aparece "Euskaltel SS", como información de célula, pero vamos, que me parece que se les han adelantado.
Espero que esta guerra que vamos a tener Euskaltel - Orange sea beneficiosa para nosotros, los usuarios. Y que aparte de pegarse en los juzgados si quieren, nos bajen los precios para motivarnos. :)

Metodologías ágiles: malas, buenas,... y la de Google

Vía JoelOnSoftware llego a este interesantísimo, aunque larguísimo, post de Steve Yegge: " Good Agile, Bad Agile". En él hace un dura crítica a las metodologías ágiles como metodología de desarrollo de software. Lo curioso es que lo que comenta como ejemplo de una buena metodología de ágil es lo que nos cuenta de cómo trabajan en Google: (traducido "más o menos")

• Existen "managers", pero la mayoría de ellos escriben código al enos la mitad de su tiempo, haciendoles más como "gurús-tecnológicos"
• Los desarrolladores pueden cambiar de equipo o proyectos en cualquier momento que quieran, sin preguntas.
• Google tiene la filosofía de no decir nunca a los desarrolladores en qué deben trabajar, y se lo toman muy en serio.
• Los desarrolladores son fuertemente animados a gasta el 20% de su tiempo (de horario laboral) en trabajar en lo que ellos quieran, con tal que no sea en su proyecto principal.
• No hay muchas reuniones. Quizás de media tres por semana, incluyendo una charla con su líder.
• Hay tranquilidad. Los ingenieros están silenciosamente centrados en su trabajo, individualemtne o en pequeños grupos de 2 a 5 personas.
• No existen diagramas de Gantt o hojas con tareas-personas-fechas ni otros artefactos de gestión de proyectos visibles, no que yo haya visto.
• Incluso los relativamente raros periodos de estrés, la gente todavía va a comer y cenar, las cuales son gratuitas, y no se trabaja en horas intempestivas a menos que se quiera .

Vaya, Impresionante, no? Seguro que se te hace un poco raro trabajar en una empresa así. No parece una empresa típica-media de desarrollo de software, al menos de las que yo he pasado o conozco. En el artículo comenta que hay tres tipos de empresas que funcionan más o menos así: las "start-ups", las universitarias y Google. el mérito de Google es haber mantenido ese tipo de trabajo con su escala actual, con el tamaño que tiene, sin haberse burocratizado.
Pero de todas maneras ¿es esto una metodología ágil? más bien creo que esto son directivas de funcionamiento de la empresa, o su filosofía, pero de ahí a poder afirmar que estas técnicas son las buenas ágiles, y las de XP o Scrum las malas, me parece que va un abismo.
Hay que diferenciar claramente dónde y para quién se desarrolla el software. Según parece en Google !no tienen presiones con las fechas de lanzamiento! Vamos, la panacea. Parece que el interés de los desarrolladores en crear algo ya es suficiente. Cuando el proyecto está terminado, se lanza. ¿Dónde hay que firmar?... Pero bueno, en el mundo real, los clientes presionan, los de márketing anuncian un producto mucho antes de su finalización, los directores cuentan ya con sus ingresos... o sea, que las fechas existen, y sobre todo, un día llegan.
Y ahí es precisamente donde creo que las metodologías ágiles ayudan con sus ciclos cortos de desarrollo (entre otras cosas) para poder acercarse las fechas objetivo con productos cada vez más cercanos a las peticiones reales de los clientes.
Sin duda un gran artículo que os recomiendo leer sobre el funcionamiento interno de Google. Un funcionamiento que dificilmente puede ser extrapolado a otro tipo de empresas de software, pero del que se podrán aprender muchas cosas. Otra cosa es que como crítica a las metodologías ágiles ande un poco desencaminado, pues compara metodologías muy pragmáticas, con filosofías de empresa, que para nada son incompatibles, simplemente son niveles distintos en muchos aspectos.
Eso sí, un día Google dominará el mundo :D aunque sea únicamente por que tendrá los mejores desarrolladores de software. Bueno, menos a mi, que me pilla un poco lejos.

NO a Patentes de software

Llego a través de Kritópolis a esta página con acciones concretas para hacer algo contra las patentes de software que intentan legalizar de nuevo, y a hurtadillas, en Bruselas.
Los conceptos que podemos dar para oponernos a las patentes los explica así:

• "El EPLA dañará severamente a las PYME europeas a base de pleitos de patentes incosteables e innecesarios."
• "El EPLA legaliza las patentes de software (por vía de jurisprudencia, como hicieron en EEUU)".
• "El EPLA es la puerta a los parásitos y extorsionadores de patentes ya tristemente famosos en EEUU"
• "El EPLA es el golpe de estado de la no democrática ni comunitaria Oficina Europea de Patentes para lograr imponer su dictadura sobre las ideas y el tejido innovador europeo"

Compuntoes, o empieza el tostón otra vez

Resulta que empieza un consurso de posicionamiento en los buscadores(al que no voy a enlazar ;) ), y la palabreja que hay que posiciones es la solemne tontería de compuntoes. Así que preparaos a ver enlaces enviados a meneame, barrapunto y cualquier otro sitio para enlazar a los sitios ficticios creados para posicionar... qué cruz...

Actualización: Dos cosas. Los comentarios utilizados en este post para posicionar compuntoes, los estoy borrando :)
Y ya lo que faltaba, no es un solo concurso, si no que parece ser un buen negocio. Creo que si participase me sentiría un poco engañado.

Desconferencia CADIUS

El viernes pasado celebramos en San Sebastian la desconferencia del grupo CADIUS. En teoría este grupo trata sobre temas de diseño, pero aquí se han expandido un poco los temas que se tratan.
Las charlas fueron muy interesantes, y han ampliado mis horizontes sobre algunos temas.

• Los roles y las relaciones entre diseñadores, maquetadores y arquitectos de la información. Goio, y Miguel hablaron sobre qué papel debe jugar cada persona en un proyecto. Me he dado cuenta lo limitado de mi visión sobre este tema, pues hasta ahora no había trabajado en un equipo donde el diseño tuviese demasiada fuerza.
  
• La información georeferenciada, los metaversos (¿mapas con nombre bonito?). Luistxo nos dio una visión sobre el tema con ejemplos sobre el Google Earth.
• La generación de webs con UTF-8 permite crear webs sin problemas de idiomas, según David. Nunca había visto un blog en árabe :)
  
• AJAX y sus implicaciones sobre el diseño y la usabilidad. por Virginia. Sin duda la tecnología de moda no podía faltar en estas desconferencias.
  
• El Ranking de blogs de Alianzo. Jose A. del Moral nos habló del ranking, que además justo se actualizó ese viernes.
  
• Accesibilidad, parece que el mito se puede hacer realidad. Por Jon Tribak.
  

Fotos del magno evento: De Miguel y Virginia.

Ayuda: Programa para gestión de almacen (stocks)

Bueno, la vuelta de vacaciones ha sido un poco dura. Un par de semanas ya y sin escribir ni una linea en el blog. Y eso que tengo unas cuantas cosas interesantes en mente...
Pero ahora quería plantear una preguntica. Me consultaban ayer sobre algún programa de gestión de almacenaje. Se trata de una ONG que quiere llevar el control del stock de medicamentos de los que dispone. Supongo que con lo básico es suficiente: entradas /salidas, listados, situación en el almacen,... ¿conoceis algún software libre que pueda resultar útil y no demasiado complicado? Creo que será sobre Windows, y desconozco si tienen conexión a Internet.
FacturaLux le he echado un vistazo pero quizás es demasido complejo.
He encontrado una lista de sw. libre de gestión. ¿me podeis recomendar alguno?
Gracias!