viernes, 3 de agosto de 2012

Integrando LinkedIn en Android

En el post de hoy vamos a ver como podemos integrar de manera sencilla la red social de trabajo LinkedIn en nuestras aplicaciones Android. Para ello vamos a utilizar la librería linkedin-j, que encapsula las llamadas a la API Rest de LinkedIn y que además incorpora soporte para OAuth, el sistema de autenticación utilizado por la red social.

viernes, 20 de julio de 2012

Errores comunes de los Daily Meetings

La reunión diaria de Scrum, más conocida cómo Daily Meeting (o Stand Up Meeting), es la reunión que permite al equipo mantenerse sincronizado, comunicarse y estar al tanto del avance en los objetivos del Sprint, y aunque es una de las prácticas más utilizadas (ha sido adoptada por muchas otras metodologías) y de las que más documentación existen, todavía se siguen cometiendo muchos errores a la hora de realizarla.

image from http://kept.co.za


A continuación he recopilado una pequeña lista con algunos de los errores con los que más veces me he ido encontrando a lo largo de los últimos años:

Reportar al Scrum Master (o a otro cargo)
El Daily Meeting es una reunión del equipo. El objetivo es mejorar la comunicación y la transparencia entre los miembros del equipo no pasar un report a ningún cargo superior (ni tampoco al Scrum Master). Los miembros del equipo deben mirar a sus compañeros cuando contesten a las 3 preguntas del Daily.

Reuniones muy largas
En muchas ocasiones, sobretodo cuando participan jefes o cargos superiores,  las reuniones se alargan mucho más allá de los 15-20 minutos que marca la metodología haciendo que baje la productividad de la reunión.
Evitar preguntas que entran mucho en detalle y limitarse a una breve sincronización es la mejor manera de mantener una reunión diaria saludable y productiva.

Discusiones sobre diseño
La reunión diaria se acaba convirtiendo en el lugar donde se tienen las discusiones sobre diseño o arquitectura. Este problema hace que, ademas de alargar las reuniones (punto anterior), las personas que no estén involucradas pierdan el foco de la reunión y pasen a "perder el tiempo". Cuando aparezcan este tipo de discusiones, lo mejor es apuntarlas y que las personas involucradas se reúnan posteriormente para seguir tratando el tema.

Reporte de bugs
Los equipos de soporte o test aprovechan la reunión del daily meeting para hacer llegar los bugs o incidencias detectadas, o para preguntar por aquellas incidencias que no les han sido resueltas (el "¿que hay de lo mío?"), haciendo de nuevo que la reunión se alargue y se pierda el foco. El reporte de incidencias del estado de las mismas debería ser una reunión diferente en el caso de que fuera necesaria.

¿Qué otros tipos de problemas os habéis encontrado al realizar la reunión diaria? ¿Y cómo los habéis solucionado?

sábado, 5 de mayo de 2012

¿Eres un programador profesional?



Leyendo hace unos días el libro “97 Things Every Programmer Should Know”, una recopilación de 97 artículos escritos expresamente para el libro por expertos en desarrollo de software de los últimos años, me llamó bastante la atención uno de los artículos llamado “The Professional Programmer”, en el cual Robert C.Martin (más conocido como Uncle Bob) explica una serie de ideas sobre lo que el entiende por ser un Programador Profesional.

El artículo no sorprenderá demasiado a los que hayan leído algún libro u otras referencias del autor, ya que siempre ha dejado bastante clara su postura respecto al tema, pero me pareció que podía ser interesante como tema de discusión.

Las ideas que expone  Uncle Bob en el artículo son las siguientes (la traducción es  bastante libre):


  • Un programador profesional es aquel  que se responsabiliza de su propia carrera profesional: Estudiando, leyendo libros, formándose, estando al día en las últimas tecnologías  y metodologías y no esperar que sea nuestro jefe el que nos pague la formación.  
  •  Un programador profesional es responsable del código que escribe: No sube código a producción que no ha sido probado o del cual no se está seguro que vaya a funcionar.
  • Un programador profesional trabaja en equipo: Se responsabiliza de “todo” lo que tiene que entregar su equipo, y no únicamente de su trabajo. Ayuda a sus compañeros cuando estos tienen problemas y les enseña y aprende de ellos lo máximo posible.
  • Un programador profesional “no soporta” grandes listas de bugs: es una  señal de que se está siendo poco cuidadoso con el sistema.
  • Un programador profesional no hace “ñapas”:  Acaba el trabajo de forma correcta y sin prisas, manteniendo su código limpio , bien estructurado y lo más legible posible, siguiente estándares y buenas prácticas de desarrollo.

Para enfatizar los puntos anteriores Uncle Bob da diversos ejemplos, como los de los abogados o médicos que utilizan parte de su tiempo libre para estar el día en los diferentes aspectos y avances de su profesión, u otro ejemplo con un médico al explicar lo de las “ñapas” utilizando una hipotética situación en la que un médico está operando a corazón abierto y hace un apaño para ir tirando porque tiene que irse a casa.

La visión que expone Uncle Bob de lo que es ser un profesional de nuestro campo se acerca bastante a la idea que yo tengo de la misma. Hay alguna idea un poco cogida con pinzas (la lista de Bugs) pero en general creo que es una visión muy buena. Lamentablemente, por lo que llevo visto en mi (aún corta) carrera profesional, parece que lo que la mayoría de desarrolladores entienden por ser profesional  poco tiene que ver con esto, acercándose más a la idea de pasar 8 horas intentando hacer de manera más o menos “bien” las tareas que se les asigna y poner la mano a final de mes (en un país donde ser funcionario es el gran sueño para una gran parte de la población, esto es algo que no debería sorprender).

A pesar de ello, sigo pensando que es importantísimo el cuidar de nuestra carrera profesional, que se supone que es lo que nos va a dar de comer a nosotros y a nuestra familia, y más ahora en este tiempo un tanto “oscuro” que nos está tocando pasar, donde la actitud respecto a nuestra profesión va a ser un factor diferencial clave, y para ello, las propuestas e ideas de Uncle Bob pueden ser una gran ayuda.

¿Qué opináis vosotros? ¿Se acerca vuestra visión de lo que es un programador profesional a lo que nos cuenta Uncle Bob?