El rastreo de iPhone y Android

Hace unos días se conocía que los iPhone e iPad  de Apple guardaban un registro de las posiciones de los usuarios (más bien de sus teléfonos) y que por si fuera poco, esos datos se registraban en un archivo sin protección. Unos días más tarde, conocemos por un artículo en The Wall Street Journal, que Google hace lo mismo con sus teléfonos Android .

El tema ha creado bastante revuelo desde que se ha conocido. Corea del Sur ha pedido explicaciones a Google y el senador de EE.UU. Al Franken, ha hecho lo propio con Apple, escribiendo una carta a Steve Jobs, en la que le pide respuestas a una serie de preguntas sobre el tema.

En el caso de Apple, se disculpan diciendo que los datos de localización solo se registran cuando el usuario utiliza una aplicación que requiere localización, después los datos se envían encriptados cada 12 horas a Apple. 

En el caso de Android, la información se recoge cada pocos segundos y se envía varias veces por hora a los servidores de Google, con la diferencia de que en este caso, los datos se relacionan con el identificador único del teléfono. Google se disculpa diciendo que lo hace bajo el consentimiento del usuario.

Google y Apple, no pierden tiempo en tomar posiciones en los servicios de localización y coger su trozo de pastel en este mercado, en el que según Gartner, alcanzará los 8,3 billones (US) de dólares .

A mi personalmente, no me apetece que alguien pueda saber donde he estado en los últimos meses, aunque es por el mismo motivo por el que no tengo un perfil de Facebook donde publico las fotos de mis últimas vacaciones.

Como de todo tiene que haber en este mundo, hay quién a todo esto le encuentra la gracia y lejos de molestarles el asunto, se divierten revisando sus itinerarios y como no podía ser de otra forma, publicándolos en Facebook o cualquier otra red social, nada nuevo teniendo en cuenta el éxito de Foursquare o Facebook Places.

Al poco de conocerse la noticia de que los iPhone guardaban los datos de localización en un archivo desprotegido, estaba disponible la aplicación iPhone Tracker, una aplicación de código abierto, que permite visualizar los sitios en los que se ha estado en los últimos meses, desde que comenzó la grabación de los datos.

Si los datos de geolocalización son de fácil acceso y a eso le sumamos que los ataques dirigidos cada vez son más frecuentes y precisos, no será de extrañar que ya esté en circulación algún tipo de malware específico para iPhone, encaminado a saber donde han estado ciertas personas en los últimos meses.

En el caso de iPhone, también existe una aplicación llamada Untrackerd que borra constantemente el archivo donde se guardan estos controvertidos datos.

Releyendo Scrum y XP desde las Trincheras

El otro día se me ocurrió volver a leer el clásico de la literatura Scrum “Scrum and XP from the Trenches”, con el objetivo de comparar la aplicación de Scrum que se comenta en el libro y la que practicamos en mi organización. 

Cuando leí el libro por primera vez, antes de comenzar a aplicar Scrum, a medida que leía el libro trataba de prestar atención en aquellos aspectos en los que el autor ponía más énfasis, suponiendo que una vez inmerso en la práctica, esas cuestiones serían a las que más importancia darle. De forma inconsciente, fui haciendo una selección de estos aspectos para quedarme con un top-10.

Después de volver a leer el libro, e intentar hacer un top-10, la verdad es que lo he tenido más difícil, ya que algunas cuestiones que pasé por alto en su momento, han adquirido ahora una especial relevancia.

En el libro se insiste en que no hay una regla única para aplicar Scrum y que se debe probar con diferentes formas de hacer las cosas, hasta dar con la que mejor se ajusta al contexto donde se aplicará. En efecto eso es así, tanto que incluso si en la primera iteración de su aplicación nos encontramos cómodos, debemos probar a hacer cambios, incluso a sabiendas de que alguno de los cambios que hagamos será a peor, pero eso también sirve para encontrar el modelo óptimo para tu caso.

No se debe tener miedo a cambiar las cosas incluso si creemos que lo que hacemos ya está bastante bien. La mejora continua, debe ser una constante.

Volviendo al tema del libro, uno de los aspectos a los que se le da mucha importancia, pero que yo no supe ver en su plenitud tras la primera lectura, es el conocimiento de la velocidad de los equipos. Al principio pensé que era un indicador más, pero he observado que es vital en dos aspectos que inicialmente no di demasiada importancia: la reducción del riesgo y la mejora continua.

Reducción del riesgo: La estimación y la planificación de un proyecto, no tendrá base objetiva si no conocemos este dato y por lo tanto, estaremos más expuestos a incurrir en retrasos y sobrecostes, sobre todo cuanto más grande sea el proyecto.

Mejora continua: La evolución de la velocidad de los equipos, será un claro indicador de la madurez de los equipos, y como eso se traduce en una mejora de sus resultados. Si analizamos los picos y valles en la evolución de las velocidades y los contrastamos con acciones o cambios introducidos en los equipos, podremos sacar jugosas conclusiones.

Otro aspecto que ha adquirido una especial relevancia para mi, ha sido la importancia del artefacto “Sprint Burn Down Chart”, sobre todo si comparamos la evolución de estas gráficas a lo largo de los distintos Sprints. El seguimiento diario de su evolución permite aprender mucho de como estamos distribuyendo y abordando las historias. No hace falta asistir a todos los “Daily” para darse cuenta mirando este gráfico, de que algunos miembros del equipo repiten durante demasiados días “Sigo trabajando en X”.

La verdad es que ha sido un buen ejercicio leer de nuevo este libro, ha sido como juntarse con algún colega para compartir experiencias sobre Scrum.

No se si ya lo ha dicho alguien antes, pero se me ocurre que un buen consejo para finalizar, sería: “Se práctico y no escatimes esfuerzos en ahorrar trabajo”.

Si alguien no conoce el libro y está interesado en su lectura, se puede descargar de Internet en formato PDF, tanto en inglés como en castellano. Es una lectura amena y no lleva demasiado tiempo leerlo.

No pongo ningún enlace ya que se puede encontrar con facilidad y existen numerosos sitios de descarga.

20 años de Linux

Para algunos será una eternidad y para otros un suspiro, pero la verdad es que ya han pasado 20 años desde que el señor Linus Benedict Torvalds escribió el ya célebre mensaje de correo en el que anunciaba la creación de lo que más tarde, todos conoceríamos como Linux:

“Hello everybody out there… I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) … It is NOT portable …and it probably will never support anything other than AT-harddisks, as that’s all I have :-(”

En aquellos momentos, allá por abril de 1991, cuando Linus escribía este mensaje, no podía ni imaginarse la repercusión de lo que estaba gestando, así como tampoco lo equivocado que estaba cuando pensaba que nunca soportaría otro hardware más allá de su 386.

Evidentemente  hay mucha gente que no sabe que es esto del Linux, pero sin darse cuenta, en muchos casos lo están usando sin saberlo, en su teléfono móvil, en su cámara fotográfica o en el mismo cajero automático.

Aunque no sean los hitos más importantes en la historia de Linux, me gustaría reseñar unos pocos, que por diferentes motivos, me parecen interesantes:

• Agosto de 1991- El nacimiento: se publica la primera versión del kernel de Linux
• Abril de 1993-La primera apuesta por Linux: aparece Slackware la primera distribución de Linux y la más antigua ya que aún existe.
• 1996-Nace TUX:  Larry Ewing crea TUX, el pingüino símbolo de Linux.
• 2003-La apuesta de los gigantes: IBM sorprende al mundo con el anuncio de IBM-Linux durante la Super Bowl.
• 2010-Se abre una nueva era para Linux: Google crea Android, basado en el kernel de Linux

Aunque no lo podría catalogar como un hito, entre 2009 y 2010 la distribución Ubuntu, que aunque lleva en la calle desde finales de 2004, da un salto cualitativo acercando Linux al usuario de a pié, haciendo una distribución más fácil de usar y más amigable que otras anteriores, de hecho, actualmente tiene una cuota del 50% entre los usuarios de Linux.

Durante estos 20 años ha habido luces y sombras, pero Linux se ha mantenido firme, buscando su sitio poco a poco, a pesar de detractores como el propio CEO de Microsoft, Steve Ballmer, quién llegó a calificarlo en 2001 como:  "Linux es un cáncer que se pega a la propiedad intelectual"

A lo largo de estos 20 años, hemos ido viendo como Linux iba cambiando, algunas veces incluso a peor; el propio Linus llegó a decir en algún momento, que KDE era un desastre; pero poco a poco ha ido ganando posiciones en todos los sentidos.

La mayoría de los sitios web en Internet utilizan servidores Linux, los grandes superordenadores también, pero el desktop siempre se le ha atragantado. En este sentido Ubuntu y Android están consiguiendo cambiar la tendencia. ¿El truco?, hacer las cosas más fáciles para el usuario, esa siempre ha sido la clave del éxito. No solo sirve disponer de miles de aplicaciones gratuitas para Linux si estas son difíciles de instalar, de actualizar o de usar.

En alguna entrevista, Linus ha reconocido que Ubuntu ha hecho un gran aporte al mundo Linux por su sencillez de uso para el usuario final, aunque por otro lado también reconoce que no es cómodo para los desarrolladores del Kernel, pero ¿Cuántos desarroladores de Kernel hay?.

Donde Linus no tiene dudas es con Android, ¡está encantado!

Aunque habrá que esperar hasta agosto… Feliz Cumpleaños, Linux!!!

Factores clave en la adopción de Scrum por las empresas de TI

Las metodologías ágiles en general y Scrum en particular, están gozando de creciente aceptación y aplicación en nuestras empresas de TI. Aunque estas metodologías no son nuevas, si es verdad que en los últimos 2 o 3 años se han percibido sus beneficios de forma sustancial, todo ello motivado seguramente por aspectos externos como el propio mercado, la crisis económica, etc.

La metodología Scrum tiene unos fundamentos sencillos y aunque a primera vista pueda parecer simple de aplicar y nada nuevo respecto a lo que hemos venido haciendo tiempo atrás, en realidad no es así y aunque sus principios son pocos y sencillos, es imperativo seguirlos para que la aplicación de la metodología consiga el objetivo.

Sin entrar en detalle de como se aplica la metodología, que significan sus roles, artefactos, métricas, etc., si me gustaría señalar algunas cuestiones clave para la aplicación de Scrum y sobre las cuales merece la pena reflexionar antes de adoptar esta metodología.

En cualquier caso, antes de plantearse adoptar Scrum como metodología de trabajo, habrá que pararse a pensar si cumplimos ciertos requisitos o qué podemos hacer para cumplirlos antes de comenzar.

Aunque hay muchos aspectos importantes a valorar, como por ejemplo la comunicación, la implicación del cliente, la estabilidad, etc., quiero centrarme en dos que para mí tienen una especial relevancia: El Cambio organizacional y el Compromiso del equipo.

El cambio organizacional

Por lo general, en la mayoría de las empresas, existe un organigrama demasiado jerarquizado, que no encaja demasiado en la definición de roles de Scrum. En este sentido, la dirección de la empresa debe remodelar la estructura para “achatar la pirámide”.

El cambio organizacional, es quizá el más controvertido a la hora de aplicarlo. Ya no tiene sentido hablar de Jefe de Departamento, Jefe de Proyecto, Analista Funcional, Analista Programador, Programador Senior, etc. donde cada uno parecía tener sus funciones acotadas y de la misma forma que representaba la estructura, se procedía a un trabajo en cadena, donde cada uno hacía una parte y se la pasaba al siguiente. Esto en Scrum ya no tiene sentido.

Es un error habitual, es asimilar el rol tradicional de Project Manager al de Scrum Master. Un Project Manager puede convertirse en Scrum Master, si sus skills le permiten ser un facilitador, pero ya no tiene por que ser un buen gestor. Ahora el equipo se autogestiona.

Es complicado para la empresa, acometer un cambio en la estructura, pero seguramente es más complicado para las personas, que de repente pierden su “status” y se disuelven en un “Scrum Team”. Esto hay que saberlo gestionar adecuadamente para que se traduzca en una oportunidad en vez de una amenaza para las personas.

El compromiso del equipo

En Scrum, el equipo y el trabajo en equipo adquieren una nueva dimensión, ahora el equipo es un ente con atribuciones que hasta ahora, solo recaían en ciertas personas en particular. Ahora el equipo se autogestiona y toma sus propias decisiones.

El objetivo es pensar en el equipo como un ente único, pero queramos o no, los equipos los forman las personas y las personas tienen sus virtudes y sus defectos.

Las personas brillantes son siempre bienvenidas en todos los equipos, pero el problema surge cuando alguna de estas personas por ego profesional o personal, trata de imponer sus criterios o manipular al resto del equipo. Las individualidades deben supeditarse al equipo y el éxito o el fracaso es siempre del equipo, no de las personas por separado.

Cualquier persona, siempre tiene algo que aportar al equipo, solamente es cuestión de buscar que es y aprovecharlo. No sirve dejarse llevar, siempre hay que aportar.

Dentro del equipo, las personas deben confiar unas en otras y ser transparentes en su trabajo, si no es así, deberán cambiar algunos de sus anteriores hábitos.

El cambio de mentalidad puede llegar a ser un problema si no se gestiona adecuadamente por parte de la organización. En este sentido, será preciso hacer una labor de mentalización y convencimiento para que las personas tengan claro que su apuesta debe ser por el equipo.