bitácora de uno

En el equipo de desarrollo de Osmius utilizamos como metodología Scrum, que como ya he mencionado no es más que sentido común estructurado.
En alguna ocasión hemos usado Google Wave para hacer las reuniones diarias de Scrum, pero como éstas siguen un orden cronológico claro es mucho más sencillo utilizar culaquier herramienta de Chat y dejar Wave para cuando queremos “discutir” algo a base de teclado.

Os pongo la reunión diaria de hoy, cuarto día del Sprint de Osmius para la versión de julio de 2010 (Osmius 10.07):

[08:16:38] Joselu: Bueeeenossssss diiiiiiiaaaas!!!
[08:17:02] Cesar: buenasss
[08:17:12] jpan: hola;
[08:17:17] Joselu: César: Ayer y hoy;
[08:18:13] Cesar : ayer: empecé la migración de los datos de la .com pero no me dió tiempo a verlo con David todo asi que me puse con otras pantallas: agents y formularios
[08:18:22] … problemas: 0
[08:18:29] … retrasos: 1 hora de adelanto
[08:18:43] Joselu: Ok. Jesús?
[08:18:47] Cesar: hoy: terminar agentes y documentación que no me queda nada
[08:19:05] … y dependiendo de si viene David seguiremos viendo lo de la migración y si cojo otra pantalla
[08:19:10] … si no
[08:19:17] … ;
[08:19:20] jpan: Ayer: Terminacion mediante eventos windows de procesos servidor y master agent
[08:19:31] … Hoy: Terminacion mediante eventos windows de agentes
[08:19:36] … Problemas No
[08:19:39] … Retrasos 0
[08:19:41] … ;
[08:19:49] Joselu: Ok, Chico?
[08:19:54] Chico: ayer: test migración JDBC Template y Acentos Consola
hoy: Acabar Acentos Consola y Librería ficheros .ods
problemas:no (pero en mis pruebas con 2 equipos no consigo que me peten los acentos)
retrasos: 5 horas adelanto;
[08:20:15] Joselu: (usa el de Jeśus ). Manuel?
[08:20:22] Manuel: ayer: oracle, soporte e instaladores
hoy: oracle, soporte
problemas: no
retrasos: no
[08:20:33] Joselu: Ok, yo?
[08:21:00] … Ayer: Terminé de definir los eventos y me enteré mejor de lo que van los aparatos eléctricos.
[08:21:32] … Hoy: Desarrollar uno de los agentes (si me da tiempo hago dos, sino lo vemos en el siguiente Sprint).
[08:21:39] … Problemas: No
[08:21:44] … Retrasos: 0
[08:21:46] … FIN
[08:21:55] … Preguntas, temas?
[08:22:06] jpan: Nonaino
[08:22:13] … a currar
[08:22:14] … besos;
[08:22:36] Joselu: Daos de alta en el Campus de Escuela de Groovy, si queréis;
[08:22:43] … Bye;

Osea que en 6 minutos ya sabemos como vamos y nos ponemos a currar, a tachar tareas.

Parte de las labores en el departamento de I+D en el que desarrollamos Osmius son las de decidir hacia dónde vamos.

En nuestro caso trato de plantearlo, de forma profunda y sin permitir tabúes, al menos una vez al año. La idea es no casarnos con nosotros mismos y tampoco con ninguna tecnología, o dicho de otro modo dejar que surjan dudas y luego intentar resolverlas con argumentos.

Algunas preguntas tipo que nos hacemos son:

• ¿Tenemos que cambiar profundamente alguna parte del desarrollo?
• ¿Debemos orientarnos hacia el Software como Servicio?

Pero de igual manera trato también de que nos replanteemos la tecnología que utilizamos y no sólo el roadmap de producto, aunque es verdad que en el desarrollo de software están bastante relacionados.

En una de éstas me di cuenta de que el desarrollo de la parte Web de Osmius, era lento, pesado, poco ágil y no por la gente de equipo sino porque es algo farragoso, editando 15 xmls para hacer una pantalla de mantenimiento de toda la vida y otras lindezas imperdonables. Un salto atrás en el tiempo si pensamos que con Visual Basic 3.0 ya era fácil desarrollar pantallas hace tropocientos años (unos 10, que en TI representan eones).

En éstas contacté con Álvaro y Nacho de Escuela Groovy para que primero nos convencieran razonando para utilizar Grails y Groovy y, segundo, para contratarles un curso que nos sirviera de comienzo. Finalmente hicimos el curso y estamos trabajando para aprender e incorporar la tecnología a nuestros desarrollos.

La razones de la elección se apuntan en las siguientes líneas:

El Producto: Osmius es un software de Monitorización de Sistemas y Servicios que tiene componentes:

• Procesos del “core” para monitorizar a toda velocidad y con poca carga -> C++
• Consola Web Java + Spring + Hibernate + JQuery + Spring Security con más de 50 pantallas y Web Services.
• Más 130 tablas en el Modelo de Datos.
• Metodología de trabajo Scrum

Necesidades a cubrir:

• Aunar la agilidad que ya disfrutamos en la metodología con el desarrollo.
• Peticiones de los usuarios: Más rápido, J2EE es muuuuyyyy lento.
• Actualizar a los Dinosaurios (equipo C++) y a los Cromagnones (equipo Java)

Grails y Groovy porque:

• La sintaxis de groovy no es extraña para Dinosaurios ni Cromañones.
• Podemos integrar Scripts de groovy en la monitorización (cuando el rendimiento salvaje no sea un problema).
• Reutilizamos conocimiento de Cromagnones: Spring, Hibernate, etc.
• El rendimiento no nos preocupa porque el core es C++ y tenemos muy optimizadas las sentencias a BBDD.

Curiosidades:

• Cromagnones: Están encantados, sobretodo con no tener que tocar quince XMLS cada vez.
• Dinosaurios: Están horrorizados. “El desarrollo Web es un infierno” (Vienen de Visual Basic: Arrastro control, click, código).

Ahora estamos dos del equipo en el evento sobre Spring y Grails en Madrid 2010: Spring2GXDay

El año que viene volveremos a ponernos en duda. Ya os contaré. ¿Roo, quizás? (No creo)

Este pasado viernes por fin nos reunimos para discutir y tratar un tema que llevábamos tiempo con ganas de compartir:
“Buenas Prácticas para Empresas con Producto Software”

Lo que inicialmente iba a ser un café técnico con Daniel López de BitRock, acabó siendo una reunión de 15 personas en el Bar Arrebato en Madrid,que Fernando tuvo la amabilidad de abrir en exclusiva para nosotros. El formato no estaba claro pero sí queríamos evitar que cualquiera, yo el primero, les diera una charla unidireccional al resto; no queremos Conferencias, queremos Des-conferencias.

Aunque finalmente no se des-organizó como tal si creo que cumplió aquello de ser concreta y que permitiera exponer inquietudes y escuchar a todo el mundo.

Algunos temas que se trataron:

• ¿Hay un modelo de negocio para el OpenSource?
• ¿Es posible no abrir al menos parte del producto sin dañar demasiado las posibilidades de éxito?
• La nube ¿es una moda? ¿cómo aprovecharse o mejorar o preparar nuestros productos para ella?
• Seguimiento de potenciales clientes en la Web: ¿Cómo seguirlos? ¿qué herramientas nos ayudan?
• Software como Servicio: ¿Es lo que va a quedar? ¿Cuándo entrarán las grandes empresas españolas?
• Producto y Estrategia ¿Cómo definimos objetivos y el plan anual (y presupuestos)?
• Reparto de esfuerzos y recursos: Desarrollo - Marketing - Ventas
• [usad los comentarios, si queréis para completar esta lista]

Todo en un ambiente relajado pero no por ello dejó de ser atento, intenso.

Tuvimos participaciones de fuera del Grupo TiBi como la de Justo Hidalgo y la de Marc Fleury y creo que para las siguientes vamos a abrir esto a más gente interesada aunque siempre con invitación y nunca multitudes. El “Community Management” amenaza ya como tema para una desconferencia en Marzo de este año.

Volviendo al título del post y en lo que respecta al secreto, éste - si es que existe - sigue siendo un secreto. Cuánta gente y consultoras no viven de la consultoría de la obviedad: dicen obviedades que por obvias parecen interesantes y así justifican facturas desorbitadas cuando al final no suele haber más secreto que trabajo, sentido común y suerte.

En el último año he conocido a varios emprendedores que han conseguido el éxito de sus productos, y en todos los casos han hecho referencia a la suerte. Trabajo, buen hacer y cariño seguro que no han faltado pero todos coinciden en no basta con eso y que el ingrediente que falta muchas veces no depende de nosotros y por eso lo llamamos suerte.

El cierto momento de la desconferencia, se habló de invitar a diez personas a las que les ha tocado la lotería para unas “Jornadas de Secretos para el Éxito en los juegos de Azar”.

A buen entendedor ….

-

Algunos links:

• The Four Steps to Epiphany de Steve Blank
• Lean startup de Steve Blank
• HeadCount en Joel on Software
• ¿Ideas o trabajo? (via I. de Gracia)
• [más en los comentarios, quizás]