Bosco Curtu

Archive for the ‘Gestión Proyectos’ Category

Es solo una anécdota, un compendio de mala suerte, pero una vez más Amazon AWS la lía. Me pasó con la migración del amigo invisible online al AWS EC2. En agosto lo reprogramé todo en django y lo subí a una microinstancia gratuita de amazon para nuevas cuentas. Programé el SES para el envío de emails… Todo bien, hasta más o menos un mes después.

Amazon aterrizó en España en septiembre y abrió su tienda online. Como todo bicho viviente me pudo la curiosidad y me “registré” en amazon España. Entonces tuve un conflicto de cuentas, me dijo que mi cuenta ya existía, que si la quería fusionar o no se qué. Las fusioné, curioseé y me fui.

Entonces fue cuando me di cuenta que no podía acceder a mi amigo invisible, ni por web, ni por ssh. Accedí a la consola, y no podía entrar! No tenía cuenta en AWS!!!!! Pánico. La siguiente sorpresa fue que la asistencia técnica cuesta 50€ al mes, una berbaridad.

Abrí un hilo en el foro gratuito, muy cutre. Envié un email al servicio de facturación… Lo único que me dijereon es que mi cuenta no existía (uffffffff) Bueno, me abrí otra, reinstalé todo y en 24 horas volvía a tener el sistema funcionando (ojo, había perdido 5000 sorteos…)

Lo más absurdo de todo es que días después me vuelven a escribir que habían encontrado mi máquina!!!! No se lo que pasó, nunca me lo explicaron, pero la fusión de las cuentas debió ir mal y me la liaron. Realmente mi servicio es pequeño y gratuito, no perdí dinero, solo tiempo, pero qué habría pasado si mi servicio fuera premium?

Espero que solo sea una anécdota, mis otras cuentas y proyectos en AWS siempre han ido bien (incluso con el incidente del rayo) pero acojona.

Y se hizo la luz. Tras 4 meses en fase beta privada hoy hemos lanzado la segunda fase del proyecto, abierta a todos. Hemos rediseñado toda la web, pero manteniendo y mejorando todas las funcionalidades. Mucho más fácil de usar, más atractiva y, en definitiva, mucho más útil.

La hemos testado a fondo (más de 1100 tickets resueltos), aunque siempre quedarán cosas. Sin embargo nos sentimos muy cómodos y orgullosos de esta release. Las principales características:

• Tenemos todos los eventos de Madrid y Barcelona (más de 200 diarios), con toda su descripción, vídeos, enlaces a su web, venta de entradas…
• Un motor de recomendaciones personalizado, para descubrir lo que más te pueda interesar.
• Agenda personal de eventos, para que gestiones tu tiempo, y lo compares con el de tus amigos o lugares favoritos.
• Acceso a tu ADN, es decir, lo que conocemos de tí, para poder modificarlo y cambiar tus recomendaciones
• Un explorador para buscar eventos de forma muy fácil
• Búsquedas más populares, y tus últimas búsquedas a un click, para que no necesites volver a filtrar tus búsquedas más frecuentes.
• Mapa de calor, donde se ve fácilmente los puntos más activos y atractivos de la ciudad
• Planes destacados y vistas rápidas de los planes más populares, para hoy, mañana, fin de semana…
• Sistema de mensajería muy mejorado. Acepta o rechaza Invitaciones a eventos, amigos…
• Tu privacidad, es muy importante que te sientas agusto en nuestra web. Puedes controlar quien te ve, quien te puede contactar…
• Integración segura con Gmail, Yahoo, Live Mail (hotmail), facebook…

Y todo hecho con software abierto: linux, mysql, python, django, nginx, memcached.

Ahora os toca a los usuarios opinar si todo lo que digo es cierto. Daros de alta, votad los eventos, haced vuestros planes y gestionar vuestro ocio desde dooplan.com

Robert me pasó estos dos links sobre otras formas de hacer burndown charts. Pero no he venido aquí a hablar sobre eso, sino sobre los errores que estoy cometiendo con mis burndowns. Hoy hemos terminado otro sprint más, y revisando la gráfica indica que casi hemos cumplido el objetivo, estamos a solo 1.5 puntos. Sin embargo no estoy de acuerdo completamente, porque hay un par de tareas que no hemos terminado y no podemos olvidarlas.

El error se basa basicamente en la contabilización de los puntos. En el sprint anterior terminamos 15 puntos por debajo de lo establecido, porque hicimos muchas tareas no previstas para ese sprint, pero sí previstas en el proyecto. Es decir, adelantamos tiempo y el burndown señalaba correctamente que íbamos rápido.

Sin embargo, en este sprint hemos añadido nuevas tareas que van saliendo, pero que no las reflejo en el product backlog. Ahí está el error, parece que hemos avanzado mucho, sin embargo la distancia final sigue siendo la misma.

En resumen, todas los stories nuevos que se añadan durante un sprint, deben contabilizarse en el burndown del proyecto, pero no deben influir en el del sprint, porque sino no puedes apreciar el verdadero avance de tu trabajo. O, si se quieren realizar en ese sprint, lo que también hay que modificar es el número total de horas del mismo.

El tema del hosting, lo había dejado sin comentar. Al final ni Colt, ni BT, ni Telvent, nos hemos quedado con Azamedia. Azamedia es una empresa pequeñita, revenderora de hosting y de servidores dedicados. Tienen sus máquinas alojadas en un CPD de Zona Franca (mismo edificio que Telvent) llamado Centro de Datos y tienen todas las garantías de funcionamiento que las grandes: redundancia de alimentación, control de acceso restringido, equipos anti incendio, 3 o 4 líneas de comunicaciones sobre dimensionadas…

Por parte de Azamedia, además de revender las máquinas lo que nos proporcionan es un servicio personalizado totalmente a medida. Nos han instalado todo el software que queríamos, las versiones que necesitamos, upgrade del sistema operativo… y lo han configurado a nuestro gusto. Y además lo monitorizarán 24×7. Esto que parece algo de cajón, en Colt y compañía no nos lo permitían. Que el web server tiene que ser apache, que el balanceador hw, que el S.O… Si tengo un servidor dedicado será para que pueda instalar lo que a mi me apetezca!

El lado negativo del asunto es que Azamedia es una micro empresa. Ponen todo su esfuerzo y su dedicación en el negocio, pero la ley de Murphy está ahí y el riesgo existe. Evaluaremos los primeros meses, que serán de poca actividad, a ver si el número de incidencias es bajo. Yo creo que a pesar de esto, las ventajas compensan el riesgo.

El viernes pasado terminamos el segundo gran sprint de dooplan. Esta vez hemos tenido una desviación de 15 puntos, pero 15 puntos positivos! Es decir, hemos adelantado casi 1 sprint-hombre! El sprint tenía planificados 36 puntos y finalmente hemos hecho 51. Enhorabuena doovelopers!

Pero esto tiene su lado negativo, significa que hemos estimado como el culo, y con mieditis. Está bien ser conservador en las estimaciones, pero si te pasas de negativo al final la planificación no sirve para nada. Eso sí, mejor pasarse en 15 puntos, a que falten 15.

En la retrospectiva del sprint ha salido (otra vez) la falta de testing. Hacemos muchas features, pero apenas unit testing y mucho menos user testing. Deberes para esta, hacer unit testing por cada feature.

Otro problema que nos estamos encontrando y que al final sufriremos las consecuencias es la falta de maquetación. Nos falta el perfil maquetador CSS que se encargue de consolidar y fusionar nuestros desarrollos con el diseño de la web. Vamos avanzando, pero las páginas se quedan sin maquetar. Al final veremos si hay que hacer modificaciones para que el diseño encaje, o es el diseño quien se adaptará a las features.

Por último, según vamos desarrollando historias y cerrando puntos, surgen otro nuevos. Una feature que a priori puede parecer sencilla, puede provocar nuevos cambios. Intentamos minimizar estos cambios y cerrarlos en la historia, pero a veces no es posible, así que se acumulan nuevas historias en el Product Backlog.

Pues nada, maña empezamos nuevo sprint, a ver si seguimos en racha…

El viernes debíamos cerrar el sprint, pero tuve que irme a Donosti por una boda, así que lo retrasamos a ayer lunes.

Al final casi logramos los objetivos. Solamente nos fallaron la tarea de la gestión del CPD (COLT, BT, TelVent), que se está alargando muchísimo, y la del L&F inicial, que el diseñador va saturado y no nos ha podido entregar las primeras maquetas.

Lo demás muy bien, acertamos bastante en las estimaciones. En eso ayuda el definir historias muy cortas (divide y vencerás!), la experiencia de cada uno y el hacer la estimación individualmente y discutirla en grupo. Así se aclaran dudas, salen a la luz potenciales problemas… Pero ya veremos en la siguiente.

Para el resumen del sprint convocamos a Carlos (coordinador del proyecto) y Roger (marketing) a que vieran la demo de lo que habíamos hecho, con el objetivo de que pudieran identificar carencias o simplemente pudieran tener una visión real del producto. Implicar al “Cliente” es fundamental en la metodología Scrum, y el poder ver cuanto antes el avance es muy importante.

El motor de recomendaciones tiene una calidad suficiente, similar a Amazon (según dicen). Tengo implementados dos métodos, el User Based Recommendation (USB) y el Item Based Recommendation (ITB). Dando el primero un mejor resultado, aunque me temo que cuanto más eventos tengamos, el USB irá a peor.

Como errores han salido el que no hemos definido correctamente lo que queríamos hacer. Nos pusimos a saco y a mitad de desarrollo nos dimos cuenta que no sabíamos a dónde íbamos. Para este sprint actual tenemos pocas historias funcionales, pero estas pocas las definiremos mejor.

El diagrama BurnDown funciona muy bien como indicador de progreso, es muy clara en cuanto al avance del trabajo.

Y el Product Backlog, aunque extenso, lo he refactorizado para que sea más claro y útil. Nos muestra, según las estimaciones iniciales, los story points totales del proyecto, que al comparar con los reales (nos quedan muy pocoso días hasta la salida a producción!) ya vamos viendo que debemos cerrar las funcionalidades de esta release.

Por último, además del Backlog y de los tickets en el Redmine, llevo el mantenimiento del GANTT para identificar hitos, asignaciones, fechas… Son 3 mantenimientos de la misma información y la verdad que es costoso. No hay alguna forma DRY de gestionar las múltiples vistas del proyecto?

Una rápida reseña. La semana pasada estuve en el centro de datos de COLT, viendo los servicios e instalaciones que ofrecen, y esta martes he estado en lo mismo pero de BT.

Las instalaciones de COLT son aparentemente superiores a las de BT. Digo “aparentemente” porque son claramente más bonitas, limpias, asépticas… pero en cuanto a servicio, suppongo que son muy similares. En ambas nos enseñaron los sistemas de generación eléctrica alternativos, tienen sus espacios para clientes, los CPDs de BT son más desordenados, pero al fin y al cabo tienen sus racks perfectamente acondicionados y con las medidas antiincendio necesarias.

Luego está el nivel de servicios. Mientras que en COLT son más estrictos y con mínimos más elevados, en BT tienen servicios más básicos. En COLT el mínimo de contratación es un AT1 24×7, en BT una simple monitorización a base de pings. En BT además tienen una gama de administración de software más alta, no me pusieron mala cara por querer usar FastCGI.

En definitiva, COLT tiene mejor pinta, de más profesionalidad, pero con BT tienes un servicio más a medida. A ver precios (todavía no tengo de ninguno)

Mañana visito a TelVent, la tercera grande de Barcelona (sin contar con Telefónica). A ver que cuentan.

Se me había olvidado comentar que usamos Google Apps para toda la gestión de cuentas de correo, y agenda corporativa. Es realmente facil de configurar y te llevas por la cara hasta cuentas de GMail bajo tu dominio.

Además, puedes tener abierto tu GMail personal y el corporativo y no hay conflicto de sesiones. De todas formas, lo tengo todo redireccionado y etiquetado a mi correo personal, y ya me está bien.

Pues eso, una forma barata y potente de gestionar el correo de empresa.

Este no es un post sobre correr, sino sobre dooplan! Ya he contado que seguimos Scrum, y scrum divide el desarrollo en sprints. Cada sprint consta de unas 3 semanas, y el nuestro actual va por la segunda.

Este ejercicio de autocrítica deberíamos hacerlo al final del sprint, que lo haremos, pero puedo ir avanzando ciertos detalles, que ya hemos comentado todos por lo evidente…

La cosa es que no vamos mal de planificación, el burndown del sprint indica una ligera desviación, que si pensamos en los trabajos inciados pero no reportados casi no existiría. Sin embargo, la próxima semana no lograremos el objetivo del sprint y será porque no hemos elegido bien las historias.

Hemos fallado en la definición de las stories, nos pusimos a saco sin pensar qué queríamos exactamente, y eso nos ha penalizado un poco, aunque más o menos lo hemos resuelto (la próxima vez insistiremos en esto!)

Pero el segundo error ha sido meter tareas de planificación y gestión en el sprint. Por ejemplo, yo tengo asignada la story de “Alojamiento y creación del entorno de Integración”. Claro, es imposible que termine esta historia porque no depende en absoluto de mi, y porque además es completamente irregular. Desde luego tengo que encargarme del alojamiento, de comprar máquinas, de instalar el software… pero todas estas tareas las debo gestionar para que las hagan terceras personas, externas al equipo, y por ello el timming es completamente imprevisible y prolongado en el tiempo.

Creo que la solución para estas tareas no son incluirlas directamente en el Sprint, sino asignarme a mi o a quien le toque menos Story Points, porque esas horas de dedicación exisitirán, pero que no se refleje como un retraso en el sprint.

Bueno, pues eso, así satisfago la demanda de Elizabeth

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed but you’d only be involved.”

En Scrum (ver wikipedia) los programadores somos los cerdos (cariñosamente), es decir, los que nos comprometemos 100% con el proyecto. Es una metodología que básicamente se basa en el compromiso, honestidad y comunicación. Basta de documentos de 200 páginas que no sirven para nada!

Llevamos usando Scrum un par de semanas (el proyecto solo tiene 3 semanas, ya está bien…) y parece una forma divertida de trabajar. Por ahora lo estamos haciendo un poco a la ligera, solo estamos Robert y yo, tenemos muchas cosas por hacer en paralelo, pero nos está sirviendo para ir cogiendo el ritmo y para entender mejor la metodología. En general consiste en estos puntos:

• Project Backlog, donde el “Cliente” define las funcionalidades del proyecto, les da una prioridad. A partir de este backlog se definen las Tareas y los Stories, que son agrupaciones de tareas. Por ejemplo, la story “Implementar un buscador” tendría como subtarea “Definir interfaz”, “Crear el agoritmo de búsqueda”, “Crear un juego de pruebas”… Todas las historias son de bastante alto nivel y se escriben en tarjetitas de papel, para que siempre estén a la vista, se puedan anotar, cualquier persona (un cliente) pueda escribirla sin que hayan barreras tecnológicas…
• A estas historias se les da una estimación (Story Points), y todos los “cerdos” opinan. Hay una serie de reglas para estimar, pero básicamente se utiliza el conocimiento colectivo y la experiencia real. Por supuesto, como en toda estimación, siempre nos equivocaremos, así que durante el proyecto volveremos a estimar las stories cuando sea necesario.
• Como subproducto interesante está la lista Iceberg. Es decir, se ordenan las stories segun releases y se publica la lista. Las tareas de la release actual están sobre la línea de superficie, y el resto por debajo. Cuando el cliente pida nuevas funcionalidades verá como se desplazan hacia abajo otras funcionalidades, pudiendo quedar algunas por debajo de la superficie, es decir fuera de la release.
• El Sprint. Un Sprint es un periodo de tiempo de aprox. 3 semanas, donde se realizan las stories. Al principio se deciden cuales son las que se harán, se reparte el trabajo, y se realizan. Cada día se hace una reunión de 10 minutos para saber qué se ha hecho el día anterior, que se hará hoy y los posibles problemas. Al final del sprint todos las tareas deberían haberse hecho y se aprovecha para hacer una pequeña evaluación.
• Por último, el burn down. el Burn down es un informe para ver la evolución del proyecto, contando los Story Points. Puede parecer bastante obvio, pero resulta muy útil. Ver este artículo, muy educativo.

Pues eso, esta última semana de Junio Robert y yo estamos haciendo un sprint para terminar de organizar el proyecto, definición de stories, arquitectura inicial, código base (modelo de classes, motor de recomendaciones básico…) y el día 1, cuando se incorpore Hector, empezaremos el primer Sprint real de desarrollo. A ver si esta métodología funciona, al menos un poco mejor que las tropecientas que he usado anteriormente.