Unforgettable Things 2.0!!

I’ve worked hard, very hard!! and i’ve dedicated my whole free time, we already have the new version!!!  Thanks to users like Erika or Andreas, because with their comments they have encouraged me.

With the new features now you can:

- have multiple reminders.
- store reminders.
- schedule the reminders.
- Add quick reminders (only 2 clicks)

So you can see in the view, now we have two lists, one for “New reminders” and the other “Scheduled reminders”.

• New Reminders.
  • “New reminder” : Here you can add new scheduled reminder.

    

  • “Quick reminder” : Here you can add new scheduled reminder.

  • “The rest of reminder” : Each time you add a reminder, it’s automaticaly stored.

• Scheduled reminders. You can see the outstanding reminders.
• You also can delete reminders or disable outstanding reminders. You only have to keep pressed the reminder you want to delete/disable,

  • 

The application has  2600 downloads so far,  we’ll see with the new features …

Unforgettable Things!! 1.2

Well, I released my first application yestarday, in only one day, i’ve had more then 1100 downloads and enought feedback for updating the application, so I’ve just released the version 1.2!! with 3 new features:

1. Spanish version.
   

   spanish version

2. Custom Delay. Now you choose when the detection will start.
   

   Custom delay

3. Added the key “Done”/”Hecho” to the keyboard, now it’s easier to hide it.
   

   Done/Hecho key

Unforgettable things (0.1) released!!!

I’ve just published my first Android application!!

Basically the application is an alarm for absent-minded. The application reminds you about things you shouldn’t forget. For instance, you are at home and you think, when i leave, i can’t forget to check whether the gas is on or not, so you open the application “Unforgettable things” in your Android phone, set the notification “Check the gas”

Type the unforgettable thing

and leave the phone on the table. That’s it!!!. When you put your phone back in your pocket the application warns you (with sound, led and a notification) :

Once you unlock the mobile, you can see the notifications

Once you unlock the mobile, you can see the notification.

Notification details

When you touch the notification you’ll see the whole note and you can put it off.

Seeing the unforgattable thing

Basically the application detects the movement caused by the mobile going back into your pocket. The applications is also capable of detect when you stand up, so if you’re seating in a bar, you can type a note and when stand up, the mobile warns you.

Changed the subject: Android

After a long time, i’ve come back. Up to now this blog was about management but i’ve got more interests, so today i’m starting a new blog in which i’m going to write about everything and nothing:), i’ll start with Android.

2 months ago, i bought an HTC Magic (Android) and this definitely stirred my interest in Android. I love Android, it’s great stuff, very well thought-out. Developing for Android is very easy and rewarding. I used to develop for J2ME, and i was sick and tired of that shit, it’s buggy, annoying, and so on. Android is quite the opposite. You can do whatever you want, everything is enabled, and you can use all the hardware. When i started to look into Android SDK, ithought, thank god!!! everything makes sense!!.

So i’ve started my first application and this week i’m going to release the first beta (0.1), i’m waiting for MrKoala who has to the icon of the application. And once i’ve had released the application i’ll write about the code.

Félix

Aprendiendo a estimar

Después de alguna milestone con desviaciones, de quejas (no sin razón) del equipo por la poca fiabilidad de las estimaciones, hemos decidido cambiar la forma de estimar, mejor dicho hemos decidido cambiar el momento de estimar.

No me resigno a no estimar (en pro de la supuesta mega agilidad) y  si no llegamos y el proyecto no se entrega no pasa nada, ni al “llegamos como sea” aunque sea no duermo. Ni trabajar por demás ni trabajar para nada.

Hemos pasado por varios métodos y todos con poco acierto, Pert, delphi, experiencia, etc. El problema de que la estimaciones no funcionen en iteraciones de menos de un mes no es tanto la desviación como la desconfianza del equipo en el propio hecho de estimar. Hasta el punto de preguntarse de que sirve estimar o que aporta. Antes de seguir con la nueva forma que hemos adoptado intentaré responder a esa pregunta :

¿De que sirven y que aportan las estimaciones?

• Descubrir riesgos.
  La mejor forma de mitigar los riesgos es atajarlos pronto. ¿Imaginas descubrir un riesgo en el último sprint antes de sacar un milestone?. Yo no quiero ese estrés.

• Construir confianza.
  La empresa necesita confiar en las estimaciones para poder tomar ciertas decisiones, por ejemplo: Merece la pena hacer el proyecto?, merece la pena implementar esta feature?, llegara dentro de la ventana de mercado?, necesitamos mas gente en el equipo?, etc..
  La confianza también hará que el equipo pueda trabajar a un ritmo mas sostenible, más importante aún, el equipo necesita creer en las estimaciones para trabajar cómodo, de lo contrario la mayoría del tiempo trabajarán como si las estimaciones fueran un losa sobre sus espaldas.

• ¿Cómo puedo saber que requisitos meter en mis iteraciones y cuales pasar a la siguiente sino los estimo?

• ¿Cómo puedo evitar tener que hacer mil horas extras sino sé que requisitos meter y quitar?

Como programador y project manager me encuentro entre los dos y entiendo a los dos: Entiendo que la empresa necesita una estimación para saber si un proyecto es rentable, para saber si entra en el mercado, etc. Y como programador entiendo que hay cosas que no se pueden ser estimar hasta que te pones a trabajar en ello por un tiempo. Os preguntaréis como diciendo esto puedo apoyar-pedir que se haga una estimación.. Básicamente es porque creo que hay una solución intermedia.

Una cosa más, las estimaciones son solo eso, estimaciones.

Tal y como dice Craig Larman lo normal de las desviaciones es que sean mas certeras a medida que avanzas en las iteraciones, como se puede ver en la grafico de abajo.

El problema viene cuando tus iteraciones son completamente diferentes unas de otras, como si fueses proyectos completamente diferentes, con una fuerte carga de I+D. Básicamente esto es con lo que vivimos en nuestro equipo. Por lo que nosotros no ganamos más seguridad a medida que avanzamos. Después de alguna iteración y a través del gráfico de avance nos hemos dado cuenta de que las estimaciones siempre se iban, o cortas o largas, pero no eran certeras y después de unos días la situación de repente se estabilizaba como si de repente el equipo hubiera visto la luz. Y claro que ve la luz, básicamente lo está ocurriendo es que el equipo es capaz de analizar una vez que se ha metido en harina, después de 2 días pegándose con el proyecto, de ver el código, de empezar a lidiar con el problema de verdad, es cuando pueden decirte con más seguridad que tienen por delante.

Lo que vamos a intentar es mover el momento de la estimación. Hasta ahora el equipo desglosaba los requisitos elegidos (normalmente por el cliente) en tareas y las estimaba, dependiendo de la estimación se quita o añade para cumplir dentro del time-boxing, después el equipo empezaba a desarrollar. Ahora se le entregará al equipo los requisitos, el equipo durante unos días (no más de 3 ó 4) empezará a desarrollar (sí, a lo bruto) y después de esos días el equipo se reunirá de nuevo, en ese momento hará el desglose en tareas y las estimaciones de las tareas.

Amarillo: Estimado. Verde: Real. En la línea verde puedes ver como después de unos días la estimación se estabiliza

Ya comentaremos el resultado, si ha sido un completo desastre o si ha tenido algún resultado positivo.

Si tienes algún comentario, corrección por favor házmelo saber que como dice el título, estoy aprendiendo.

Claro que soy ágil, por dios!

Yo después de 2 semanas de prácticas ágiles

Con el hype que tiene lo agile, todo programador que se precie dice querer usar metodologías ágiles para mejorar la qué actualmente usan y/o para quitar burocracia, mejorar, etc. Pero estoy descubriendo que la gente desconoce lo que conlleva la palabra “ágil “ y que se centra en cosas como “autogestión”, menos burocracia, etc. pero a la hora de realizar otras practicas que también proponen las metodologías ágiles cuanto menos salen corriendo . La mayoría de practicas se basan en equipos participativos, predispuestos a colaborar no solo con ellos, también con el resto de participantes del proyecto incluido el cliente, a asumir ciertas responsabilidades que van mucho más de allá de programar.

Así que me hago una pregunta, ¿está tú equipo preparado para usar metodologías ágiles?, normalmente la pregunta es sí la empresa está preparada, ya que no siempre es necesario ni recomendable usar metodologías ágiles, ya Craig Larman en su libro “Agile & Iterative development” recomienda a las empresas no introducir metodologías ágiles por ejemplo si se tiene éxito en los proyectos desarrollados. Yo empiezo a creer que para introducir metodologías ágiles también es necesario saber si el equipo está preparado, normalmente como ya comenté, ningún libro habla sobre esto, de acuerdo a JM esto es porque la mayoría de libros sobre metodologías ágiles vienen de EEUU y la actitud de los americanos a la hora de trabajar es muy diferente a la nuestra, son más colaborativos, más dispuestos a tirar del carro, a arrimar el hombro y hacer el proyecto suyo, vamos a estar comprometidos, sea como fuere, la realidad es que casi ningún libro habla sobre si un equipo está capacitado para usar metodologías ágiles. Como programador me hago algunas preguntas para saber si yo estoy capacitado o no:

1. ¿Acepto los cambios?. ¿Cómo encajo cuando alguien me propone cambiar algo que programe en el último sprint, incluso aunque siga iteraciones fijas y por tanto tenga garantizado que la implementación no será inmediata sino que ira al “product backlog” ?

2. ¿Sé y/o quiero trabajar codo con codo con el cliente?. Buen punto éste, soy capaz de trabajar con el cliente y aceptar sus proposiciones y/o saber canalizarlas hasta alcanzar lo que él realmente quiere?. Normalmente los programadores no trabajamos directamente con el cliente sino que hay un persona encargada de ello (por ejemplo el project manager), pero esto desemboca en el punto 1.

3. Client driven planning. Estoy dispuesto a que las funcionalidades de cada entrega/release las marque el cliente?. Para mi esto esto es el ideal, toma de requisitos continua y por tanto cambio/cancelación/modificación de requisitos actuales.

4. Daily meeetings. Estoy dispuesto a salir de mi nicho para una reunión diaria en la que se comenta lo que se está haciendo, lo que se va hacer, etc?

5. Estoy dispuesto a participar en proceso continuo aportando para crecer como grupo o solo estoy interesado en hacer mis 8 horas e irme a casa.

6. Equipos autogestionados. ¿Soy lo suficiente maduro profesionalmente para acertar ciertas responsabilidades y tomar decisiones que pueden afectar a la empresa, más aún, soy capaz de ver las cosas desde la perspectiva de la empresa?.

7. Equipos autogestionados 2. ¿Soy lo suficiente maduro profesionalmente para acertar ciertas responsabilidades y tomar decisiones que pueden afectar al producto entregado al cliente, más aún, soy capaz de ver las cosas desde la perspectiva del cliente?.

8. Equipos autogestionados 3. ¿Soy lo suficiente maduro profesionalmente para encajar 1 y 2 y hacer que comulguen los intereses de los dos?. (Esto normalmente es tarea del project manager pero en equipos autogestionados muchas decisiones importantes son tomadas por el equipo).

9. ¿Sé que ágil != falta de proceso o falta de gestión?

Aparte de estás preguntas que me hago, creo que para que tenga éxito la adopción de una metodología ágil es necesario que el equipo sepa trabajar en equipo y esté comprometido.

Balance

Se acaba el año y como siempre toca hacer balance de las cosas buenas, malas, lecciones aprendidas, etc. algo así como un daily meeting o más bien como una reunión retrospectiva de mi vida

Ha sido un año duro, duro, duro a todos los niveles, demasiada presión, estrés, demasiadas cosas que hacer. Tan duro que por primera vez me he bloqueado sin saber por donde empezar a pesar de tener más de 20 tareas pendientes.

A nivel profesional he asumido muchas nuevas responsabilidades y no he soltado nada de lastre, eso me ha pasado factura y algunas de mis tareas se han resentido debido a eso. He seguido programando pero he ido añadiendo responsabilidades hasta terminar el año como project manager pero sin dejar de programar, claro está

Me gusta mi trabajo, me gusta liderar/gestionar equipos pero el código tira mucho y no hay nada como la satisfacción que te dan 3 líneas bien hechas, sin duda programar es mucho más gratificante que gestionar debido a que a menudo los resultados son mucho más visibles, al menos si lo que llevas son proyectos a muy largo plazo, aunque también tiene sus gratificaciones.

Llevar proyectos es algo muy complicado que requiere mucha atención, paciencia incluso yo diría que cierta parte de psicología, esto no es nuevo, pero este año lo he corroborado.  Los proyectos no son complicados, la gente si. Algo que me ha quedado claro es que el 90% de las personas son difíciles y el 10% restante son extremadamente complicadas. Tengo mucho que aprender sobre gestión, empezando por ser más organizado, afortunadamente estoy en la empresa perfecta para aprender.

Cada día me queda más claro que el nivel profesional de Unkasoft es algo inusual al menos desde mi experiencia, la persona más junior de Únkasoft sería un ser superior en cualquiera de las empresas que he estado, algo que Javi me ha dicho en alguna ocasión. Eso me hace pensar que algo debo tener yo para estar aquí , no iba a ser todo malo.

He descubierto que soy muy poco efectivo cuando tengo muchas tareas. Que las tareas de programación por regla general requieren 100% de concentración y que incluso las tareas de 5 minutos que no tienen que ver con la programación te hacen perder efectividad.

Soy muy temperamental y debo pensar más y hablar menos desde el corazón. También tengo que evitar procastinar tareas.

Después de lo negativo me voy a subir un poco la moral, cosas positivas:

• Sigo constante, tenaz aprendiendo inglés y está dando sus frutos, lento pero avanzo.

• He desterrado Windows y dado la bienvenida a Ubuntu.

• Por fin tengo nuevo secretario, se llama python

• Me he leído varios libros: Behind closed doors, Practices of an Agile Developer, Uml Distilled, Agile & Iterative Development

• He empezado un blog.

• Soy capaz de desempeñar cualquier función/trabajo gracias a la voluntad y al esfuerzo, con algún error que otro como es lógico.

• Tengo nuevos compañeros con los que congenio muy bien (más importante de lo que creía)

Del año que viene espero poco, porque cuanto menos esperas más te asombran las pequeñas cosas y cuanto más esperas más te decepcionan.

pd:  He seguido el ejemplo de la prensa del corazón y del marca, as, etc.. y he añadido una foto “sexy” para atraer público temiéndome que esta entrada no le interese a nadie

Las metodologías ágiles y el mundo real

Estoy leyendo el libro “Agile & Iterative development”, me está gustando bastante cuenta los fundamentos y bases de las metodologías ágiles, entrando más a fondo en Scrum, XP, EVO y UP, además nos muestra varios escenarios en los que se aplican estás metodologías y cómo.

Como acaba pasando en casi todos los sitios, en los escenarios, no se usa una metodología concreta sino una mezcla de las prácticas que más gustan al equipo o al líder. En estos últimos años he leído bastantes libros sobre metodologías ágiles y no deja de sorprenderme que todos den por hecho o pasen por encima lo que, a mi modo de ver, es lo más importante: que el equipo este involucrado y forme parte de la construcción del proceso.

La mayoría de las practicas “ágiles” dan por sentando que el equipo es participativo, es más, dan por sentado que el equipo acepta el proceso, que lo acepta como una parte más del trabajo. Quizá es que llevo poco tiempo en esto, pero por mi experiencia esa es la parte más complicada.

¿Cómo se levanta a un equipo y se le hace participativo?

Nosotros lo estamos intentado a base de probar de practicas ágiles , nos quedaremos con las que más nos convengan e involucren al equipo, está semana hemos añadido :

Tareas pendientes, en proceso, realizadas

Que se une a la lista actual de practicas ágiles que ya realizamos:

• Daily meeting
• Remaining hours
• Sprint Backlog
• Iteration timeboxing
• Client development
• Incremental delivery
• Creo que no me dejo ninguna.

Por último una frase de Craig Larman: “ágile” no significa caos o falta de proceso.

Se va el manitas de mi edificio

Y  mira que me  jode porque el tío me cae bien, incluso me había hecho amigo suyo. El tío es una maquina, lo mismo te arregla la luz del portal, te arregla el interfono, que te saca del ascensor en el último minuto cuando ya no te quedaba aire. Sabe hacer de todo y encima bien, fíjate hasta que punto que se lo rifan otras comunidades.

Lo curioso no es que se vaya, sino el proceso que ha desencadenado su marcha. Los vecinos del ático se han dado cuenta de que tienen que aprender a poner la luz de la escalera porque en dos semanas nuestro amigo ya no estará para hacerlo. Ayer subía en el ascensor con el del primero, le comento mi preocupación por si alguien se queda  encerrado en el ascensor en el futuro y va y me dice que el también sabe abrirlo pero que como antes estaba nuestro amigo many pues que él no se molestaba. Incluso el del segundo se ha puesto con él, ayundándole a arreglar los interfonos para aprender.

Me da la sensación de que mis vecinos necesitaban algo así, un golpe, un empujón para despertar y subir un escalón en sus quehaceres.  Total que a lo mejor lo que parecía una mala noticia, resulta que no lo es y salgo ganando. Ahora tenemos 6 manitas, nuestro amigo tiene lo quiere y yo los tengo a todos xD.

Equilibrio en el equipo

Anoche asistí a mi segunda reunión de vecinos, con los siguientes puntos a tratar:

• Limpieza de zonas comunes.
• Contrato de mantenimiento de ascensores, demasiado caro.
• Reclamación a morosos.
• Servicio de limpieza, malo y caro.
• Cerrar garajes.

Si no habéis asistido a ninguna reunión de vecinos, podéis pensar en el congreso de los diputados para imaginároslo, mucha gente discutiendo, sin ponerse de acuerdo y solo unos pocos dispuestos a arreglar la situación.

Si prestas atención, a lo largo de la reunión puedes identificar diferentes perfiles, y en cierto sentido es muy parecido a un equipo de trabajo.
El primer grupo es el de las personas estancadas, que “están a gusto como están” y no quieren avanzar más, aunque esto conlleve deterioro de las zonas comunes y por tanto perjudique al resto. Luego tenemos el segundo grupo, hay tenemos a la presi y al vice, personas atrevidas, echadas “palante” siempre queriendo avanzar, innovar, trayendo nuevas propuestas, nuevos contratos con el mantenimiento de los ascensores, jardines, etc. En el tercer grupo tenemos a las típicas personas que están dispuestas a ayudar, pero que esperan la iniciativa de otras personas para ponerse manos a la obra. Y por último, el cuarto grupo, los que harán lo que la mayoría quiere, sin mucha gana pues no están involucrados en el proyecto, en nuestro vecindario este perfil lo desempeñan varios dueños que tienen pisos alquilados.

Puede parecer que lo ideal es tener en tu vecindario gente del segundo grupo “los atrevidos” y lógicamente nadie quiere tener a los del primer grupo los que están a gusto como están, pero la realidad es que los dos son complementarios y necesarios, siempre que exista una persona que medie entre los dos, en nuestro vecindario tenemos un administrador que desempeña ese papel.
Si dejamos solos a los “atrevidos” hay muchas posibilidades de que acabemos con una piscina climatizada…en el garaje. Si dejamos solos a los del primer grupo el edificio acabará deteriorado y echado a perder. ¿Y qué hay de los otros dos grupos? Con el tercer grupo, los que necesitan iniciativa de otros, es muy probable que el resultado sea el mismo que con el primer grupo, es decir, el edificio acabará deteriorado pero además el grupo acabará frustrado puesto que la gente sí quiere ayudar. Con el último grupo dejarlos solos seguramente es lo que ellos están deseando y tú te darás cuenta de tu error cuando la mierda en la puerta del portal se coma a tu perro

Como decía, bien llevados, estos grupos se equilibran. Necesitas un grupo que innove, uno que imponga sentido y realidad, que frene la innovación hasta puntos viables para toda la comunidad, necesitas de gente involucrada dispuesta a llevar acabo las ideas de otros, el último grupo se verá arrastrado por el éxito del equipo y querrá participar en él, evidentemente tú, como líder, debes jugar el papel del administrador.

Recuerda todo grupo necesita:

1. Un líder.
2. Innovadores/optimistas.
3. Incrédulos / pesimistas.
4. Voluntarios.
5. Obreros.