martes, 28 de febrero de 2012

Team Foundation Server gratis

Pues sí, parece que vamos a tener una versión gratuita (Express) del Team Foundation Server. De esta forma, tendremos completamente cerrado el círculo de desarrollo con versiones 100% gratuitas, e integradas entre sí:
- SQL Server Express: base de datos gratuita
- TFS Express: repositorio de código y más, gratis
- Visual Studio Express: entorno de desarrollo multilenguaje gratis

Todo esto formará parte de la próxima versión de Visual Studio, reforzando la infraestructura ALM desde el punto de vista gratuito.
Más información en el link: http://blogs.msdn.com/b/bharry/archive/2012/02/23/coming-soon-tfs-express.aspx

viernes, 24 de febrero de 2012

Planning Poker

Hoy me apetecía hablar del Planning Poker. Para los que no lo conozcáis, es una técnica de estimación basada en consenso. Se utiliza en muchos ámbitos, pero es especialmente defendida dentro del mundo de las metodologías ágiles. Ha estado especialmente vinculado a la metodología XP (eXtreme Programming), pero más recientemente se ha asociado casi exclusivamente a SCRUM.
Tenéis una descripción bastante acertada en Wikipedia. Aquí vamos a tratar de ir un poco más alla. Empezaremos resumiendo cómo funciona:

  1. El grupo de estimación estará compuesto por un moderador y los estimadores (equipo de desarrollo). El Product Owner puede participar, pero no puede estimar las tareas.
  2. Cada estimador debe tener un juego de cartas.
  3. El moderador lee la descripción de la tarea (normalmente, la propia "Historia del Usuario"). El Product Owner puede aquí participar para aclarar alguna duda.
  4. Cada estimador elige una carta y la coloca boca abajo en la mesa. Cuando todos los estimadores están listos, éstos darán la vuelta de forma simultánea, cada uno a su carta seleccionada.
  5. Si las estimaciones varían mucho, los estimadores con mayor variación (más alta y más baja respecto a la media), exponen sus razones. Aquí deben participar todos, no sólo los responsables de las cartas discordantes.
  6. Repetir el paso 4 hasta que las estimaciones convergan.
Hasta aquí todo bien. Hay mucha documentación en internet sobre cómo hacerlo, incluso algún sitio web que se ofrece para que hagas el planning online de forma gratuita (http://www.planningpoker.com/). Por cierto, que esto es especialmente útil para equipos distribuidos, aunque la paradoja aquí es que precisamente las metodologías ágiles están en teoría enfocadas a equipos no distribuidos.

Sin embargo, vamos a intentar como siempre, poner algo más...

Si has llegado leyendo hasta aquí y no tienes un montón de preguntas...anda...léelo otra vez. La cuestión es que el Planning Poker no estima en horas. Ni en días. No es una unidad habitual, es la llamada "Punto de Historia de Usuario". Es decir, después de una sesión de estimación con Planning Poker, saldrás de la reunión sin saber cuándo vas a terminar las tareas. Vale, en este momento, tengo a todos los agile-fans enviándome comentarios con amenazas. No, en serio. Lo que ocurre, es que la medida obtenida con Planning poker, es una unidad relativa. Se trata de una medida comparativa. Comparamos las tareas. es decir, una tarea será estimada con la carta del "3", si creemos que cuesta el triple de tiempo que la tarea para la que se estimó en "1". Es por eso, que las tareas estimadas con cantidades grandes, se suelen dividir en tareas pequeñas, que se vuelven a estimar.

Pero sigamos. Tenemos tareas pequeñas, todas bien estimadas, y ¿seguimos sin saber cuándo vamos a terminarlas? Sí, y No. En las metodologías ágiles, especialmente en SCRUM, existe un concepto llamado "Velocidad". Este término, viene a ser el número de "Puntos de Historia de Usuario" que según los datos históricos, somos capaces de llevar a cabo por unidad de tiempo.

Ventajas de Planning Poker
  • Hace divertida la estimación (después de todo, ¿quién se niega a sentarse en una mesa y jugar a las cartas en mitad del trabajo?).
  • Intenta evitar el sesgo que proporcionan las estimaciones de los falsos expertos.
  • Promueve la participación y la colaboración.
  • Aumenta el compromiso. Si la historia de usuario entra en el sprint, estaremos más comprometidos porque hemos participado en la estimación.
  • Abstrae el concepto de tiempo. Las estimaciones se hacen en puntos, y éstos son una medida proporcional a tareas simples.
  • Facilita la colaboración y estimación en entornos distribuidos (con las oportunas herramientas).

Desventajas de Planning Poker

  • No está enfocado a usuarios noveles. Una estimación basada en "puntos", es difícil que sea de utilidad a quien no tiene ya una cierta experiencia (y no sólo en ese proyecto), tanto en estimación como en desarrollo. Sin un mínimo de conocimiento, no es posible hacer la abstracción que te permita comparar la tarea estimada con otra distinta de referencia.
  • El llegar a un consenso, no garantiza el acierto. Así es, podemos estar de acuerdo en algo, y eso no significa que sea cierto. Aquí jugará mucho la experiencia REAL. Es decir, no sólo no hay que ser no-novatos, sino que además interesa que el equipo tenga varios expertos. Por desgracia, si está delante el usuario para ayudarnos en la estimación, o hay un jefe, es posible que nadie esté dispuesto a "dar la nota", y acabe llegándose a un consenso-porque-sí.
  • Es poco serio. Venga, hay muchísimos clientes que si tuvieran que asistir en una sesión de estimación, y vieran que lo primero que se hace es sacar una baraja....se echarían a temblar (justificadamente o no). Vamos, que no es exactamente la mejor imagen de seriedad.
  • Requiere de un histórico de información. Si no tenemos una medida de la velocidad del equipo, y no tenemos estimaciones anteriores para correlacionar esas estimaciones con las horas realmente requeridas, va a ser complicado que algún día podamos encajar puntos y horas. En relación con este concepto, he encontrado un post cuyo enfoque comparto. Y es que esto de abstraer la duración de las tareas, da miedo escénico. En dicho post, propone una aproximación inicial de basarse en datos históricos, combinada con el concepto de usar la tarea más pequeña, como "1 punto de historia de usuario". Así todo el equipo tiene un referente común de lo que cuesta hacer ese "punto".
  • Cultura. Requiere una cultura ágil enraigada. No veo a un manager o jefe de proyecto sin esa cultura ágil, oir hablar de que nos faltan "3 puntos" para terminar la iteración. A más de uno le entrará la histeria y soltaría frases como: "dejate de tonterías, lo tienes que terminar el viernes".
  • Por sí solo, no es una buena fuente de estimación. Sin embargo, esta técnica por sí sola, sí es una primera estimación, y se complementa perfectamente con otras técnicas de estimación como pueden ser WBS y las basadas en históricos, u otras técnicas basadas en parametrización.
  • Este método consume mucho tiempo. La idiosincrasia y el protocolo que requieren, desde mi punto de vista, parece más enfocado a acordar un resultado, que a que dicho resultado tenga algún parecido con la realidad.
  • Los Puntos de Historia de Usuario se enfocan en estimar el tamaño de lo que se construye, y evitan la realidad de que eso realmente no importa: de lo que se trata, es de estimar cuánto cuesta construirlo. Aquí, hay múltiples ejemplos en el mundo real: el hacer algo el doble de grande, no tiene porqué costar el doble. Quizás más, quizás menos.
  • El uso de Puntos, trata también de esquivar el equívoco que se produce al consumir la mitad de horas del proyecto. En este caso, un jefe de proyecto poco experimentado estará tentado de decir que estamos al 50%. Al hablar de puntos, estamos intentando que estadísticamente hablando, el error de estimación se diluya, consiguiendo que al haber transcurrido la mitad de puntos, estemos a la mitad de la iteración. Bajo mi punto de vista, esta afirmación presupone tantas cosas, que  las veo prácticamente en la misma perspectiva: ambas respuestas están mal. y es que el haber completado la mitad de puntos, me dice lo mismo que en el primer caso (cambiando horas por puntos). Lo que sí es cierto, es que el avance no se debería expresar en horas, sino en funcionalidades. Por otro lado, la triste realidad que no podemos esquivar, es que al 50% de horas, hemos gastado la mitad del dinero. A ver como administramos lo que queda...
Al final, a pesar de parecer tan duras estas desventajas, es que la técnica está realmente bien. Como siempre, estas desventajas las tenemos que ver como riesgos que afectan al proyecto. Mi recomendación, que es la misma que el SEI y otras fuentes, es diversificar. No sólo el hecho de diversificar las personas que estiman, mejoran la estimación (en eso se basa esta técnica). Si además, combinamos varias técnicas, y sobre todo, nos apoyamos en datos reales históricos, tendremos la auténtica fuente de buenas estimaciones.

Y nada más, probadlo y obtened vuestras propias conclusiones. Me gustaría terminar recomendando una lectura relacionada, de un blog que suelo leer. Os lo dejo en este link.

jueves, 23 de febrero de 2012

Cuando la culpa es del usuario

Muy bueno. Estoy leyendo un  artículo en variablenotfound, donde el autor presenta varias situaciones históricas en que puesto que los programadores han asumido que la culpa de los fallos es del usuario, se vengan de él de alguna forma:
  1. ID-10-T: es una forma de llamar al usuario IDIOTA (del inglés IDIOT, resultado de concatenar los caracteres el código de error "ID-10-T")
  2. PEBCAK: Problem Exists Between Chair And Keyboard
  3. PICNIC: Problem In Chair, Not In Computer
  4. Layer 8 Error: en el año 1984, la organización ISO publicó el Open Standard Interconnection, donde se hablaba de 7 capas del software. La 8ª capa, como imaginaréis, corresponde al usuario.
  5. RTFM: Read The  Fucking Manual
  6. Luser: término despectivo para usuarios poco (o nada) técnicos, y que deriva de la fusión entre USER (usuario) y LOSER (perdedor). Tiene su origen en una broma en el MIT nada menos que en 1975.

Al final, vemos que los programadores, hemos dedicado desde siempre una gran parte de su esfuerzo en criticar y ridiculizar a los usuarios. Vamos, que no os vayáis a creer que es algo de ahora. A todos nos molesta que los usuarios nos hagan consultas estúpidas. Como el tono del artículo original es de humor, dejo para más adelante otro artículo para criticar este tipo de posturas. Porque sí, el usuario tiene derecho a no compartir nuestra visión de la tecnología, y sí: el usuario tiene derecho a cometer errores. No se trata de que nos dobleguemos y aceptemos que cualquier cosa que diga el usuario es Ley. Se trata de que aceptemos que el cliente puede tener una visión diferente de la nuestra, o incluso equivocarse, y debemos:
  • Localizar la causa de la discrepancia.
  • Analizar y entender la postura del usuario
  • Aprovechar ese conocimiento para reenfocar nuestro servicio en un mayor beneficio mutuo

miércoles, 22 de febrero de 2012

Frases célebres sobre la calidad

A continuación, algunas frases célebres sobre la calidad:

  • "¡No me importa si funciona en tu máquina! ¡No estamos vendiendo tu máquina!" (Vidiu Platon)
  • "Programar es como el sexo: un único error y tienes que estar soportándolo toda la vida" (Michael Sinz)
  • "Hay dos formas de escribir programas sin errores; sólo la tercera funciona" (Alan J. Perlis)
  • "Puedes tener un software de calidad o puedes tener aritmética de punteros, pero no puedes tener ambas cosas al mismo tiempo" (Bertrand Meyer)
  • "Si McDonnalds funcionara como una compañía de software, uno de cada cien Big Macs te envenenarían, y la respuesta sería 'lo sentimos, aquí tiene un cupón para dos más'" (Mark Minasi)
  • "Codifica siempre como si la persona que finalmente mantendrá tu código fuera un psicópata violento que sabe dónde vives" (Martin Golding)
  • "Cometer errores es humano, pero para estropear realmente las cosas necesitas un ordenador" (Paul Ehrlich)
  • "Un ordenador te permite cometer más errores y más rápido que cualquier otra invención en la historia de la humanidad, con las posibles excepciones de las pistolas y el tequila" (Mitch Radcliffe)
Están extraídas de este blog de José M. Aguilar. Si os han gustado, en su blog hay muchas frases.

martes, 21 de febrero de 2012

La carga de trabajo

Este artículo está inspirado en un nuevo plugin que ha salido para JIRA, y que podéis ver en detalle en este link.

Lo interesante del tema, está en la imagen con que se muestran los distintos niveles de carga de trabajo:


Es decir, de lo que se trata es de repartir la carga de trabajo, para mantener a los dos primeros iconos ocupados (por su expresión, parece que se están durmiendo), mientras que a los dos últimos...pues eso, con verlos ya se ve que están algo agobiados y conviene quitarles faena. Esto de repartir la carga, tiene poco que ver con socializar el trabajo y conseguir el equilibrio, y mucho con el proceso ITIL de "Capacity Management".

Una reflexión interesante sobre la carga de trabajo, la podemos encontrar en este link, donde se establece la ecuación:
Productividad = Motivación - Procrastinación - Carga de Trabajo

viernes, 10 de febrero de 2012

Por qué fallan los despliegues en producción

Es inevitable. Parece una ley de la naturaleza. Hemos desarrollado un software con todo nuestro cariño (vale, a veces sin tanto cariño). Hemos superado con éxito los despliegues en pruebas y pre-producción, las correspondientes pruebas en esos entornos, etc (porque...¿hacéis pruebas verdad?). Y vamos a instalarlo en el entorno de producción, llega el gran día...y el gran fracaso. ¿Qué ha pasado?

No nos engañemos, la única verdad es que algo hicimos mal. ¿Qué ocurre si vamos sin lista de la compra y nos dejamos algo? ¿A quién le echamos la culpa? Oigo excusas del estilo "es que lo planificamos bien...", "hicimos todo lo que pudimos...", "es que otras personas hicieron el despliegue...", "yo es que no estaba ahí...", "a mí nadie me avisó de que esto íba a estar así...".

Planificar un software es complejo, y exige un ejercicio de experiencia, método y disciplina, para que el resultado se acerque a la realidad. Sin embargo, en raras ocasiones el despliegue, el último esfuerzo, recibe la atención necesaria (vamos, básicamente, no aplicamos adecuadamente la experiencia, el método, y la disciplina). ¿Porqué? Analicemos un poco el tema.

Habilidades Técnicas.
Esta no parece ser la causa. Aparentemente estamos preparados para todo. Somos técnicamente competentes. No hay nada o casi nada del despliegue que se nos resista.
La verdad es otra. Aunque efectivamente, no suele ser un problema grave, las habilidades técnicas adolecen de estar sobrevaloradas por nuestra parte. Nos consideramos:
  • Power developers cuando apenas sabemos programar...
  • Arquitectos cuando apenas somos buenos programadores...
  • Expertos cuando no tenemos conocimiento ni experiencia ni para llamarnos arquitectos...
Esto, que merece un post aparte, tiene especial gravedad cuando usamos para nosotros la vara de medir tamaño "mini" (cualquier cosa que hagamos, nos convierte en expertos), y para medir a los demás usamos la vara "maxi" (para que alguien se gane nuestro respeto, ha de superar pruebas que ni la mitad de hackers en el mundo superaría).
Conocimiento del Entorno.
Esta ya sí que parece ser una de las principales causas. Después de todo, si falla la instalación es porque algo se ha producido en el entorno de producción, que era ajeno a nuestro conocimiento. Unas veces será porque no había algo instalado que debía de estar. Otras será porque falta una acción sobre el entorno (configuración, carga de datos, etc.). Sin embargo, no podemos echar las culpas a los demás. Somos los primeros responsables de identificar las necesidades (requisitos), obtener toda la información del entorno (hardware, software, horarios de acceso, ventanas de trabajo, etc). Cuántas veces le echamos al cliente la culpa de que su entorno esté configurado así o asá, de que su personal no haga las cosas que le pedimos...¿Hasta qué punto es realmente culpa suya?

Falta de Preparación.
Nos sobran conocimientos técnicos. Realmente nos sobran. Somos capaces de incorporar las últimas tecnologías (aún cuando realmente sean innecesarias). Pero falta preparación. Preparación de materiales, de avisar con adecuada antelación, de identificar las necesidades y sobre todo, falta experiencia y falta método.

Hace poco, conversaba con unos colegas profesionales en un foro internacional, sobre si era mejor utilizar una checklist donde lleváramos anotadas todas las acciones al detalle...o de si la experiencia y el "olfato" de perro viejo, eran lo más adecuado. Al final, pareció llegarse al consenso de que ambos son necesarios. Esta conversación, que espero rescatar para este blog algún día, podemos trasladarla a la disyuntiva entre usar: experiencia o un proceso detallado. Por desgracia, suelen faltar ambos. Veámoslo.

Falta de Experiencia.
Cuántas veces oigo de profesionales supuestamente experimentados, excusas para culpar a otros (o al aire, porqué no), de que su software no funciona tras ser instalado en producción. Enseguida la gente pone en su currículum X años de experiencia en programación, en tal o cual tecnología, en gestión de equipos, bla bla. Pero no he visto aún un currículum donde ponga: he instalado en entornos finales de cliente más de n-cientas aplicaciones, o cosas por el estilo. Y es que falta experiencia en despliegues. No sólo es haber trabajado en docenas y docenas de evolutivos en entornos de alta disponibilidad. Además, la clave es haber participado con éxito en el despliegue. Y cuando digo participación, no me refiero a mirar y esperar a que el cliente lo instale. Me refiero a DEFINIR los pasos y actividades de instalación...a prever las consecuencias y estados de cada uno de dichos pasos, y guiar al cliente por adelantado mediante un "Plan de Instalación".

Falta de Método.
Esta causa está muy relacionada con la anterior. Falta un método. Pero un método apropiado al cliente, a sus entornos, a su personal, a sus datos, a su forma de trabajar...
Es la misma situación que una toma de requisitos. En nuestra estupidez, culpamos al cliente "de no habernos sabido contar sus necesidades". Pues no. Es culpa nuestra, el no saber extraer la información adecuada. Los profesionales somos nosotros. El cliente sólo es...eso. ¿O es que tenemos nosotros la culpa cuando el médico nos pregunta los síntomas? Pues no. Si ser equivoca en el diagnóstico, le echamos siempre la culpa a él. Para eso es un profesional.
Pues cuántas veces me tengo yo que oir en esta profesión, justo la historia al revés. La culpa es del cliente. Que no ha sabido dar los datos, la información, los requisitos...
Creo que debería de haber una rama de ingeniería en excusas. Esa no la suspendería nadie.

Falta de Gestión.
Si las dos anteriores suelen fallar, no veamos ya la gestión. En nuestra prepotencia, nos presentamos en el servidor con le paquete de instalación, y no prevemos los contenidos básicos que un buen gestor ha de preparar:
  • Plan de trabajo
  • Recursos involucrados. Recursos opcionales.
  • Estimación
  • Plan de marcha atrás
  • Plan de contingencia
  • Plan de riesgos
Si has llegado a este punto, y has esbozado una sonrisa (especialmente con lo de la gestión), y estás convencido de que no es necesario nada de esto, éste artículo era para ti. Por desgracia, hay gente que es a las buenas prácticas como el agua para el aceite. Para ellos, tengo también en mente un post con un buen listado de excusas para diversas situaciones. Como decía un antiguo compañero:


"¿Para qué vas a buscar soluciones...si puedes encontrar culpables?"