I’ve just released a new version of Unforgettable Things!! and the first paid version. Both of them have the same functionalities, the free version has ads in the new functionalities.

Imagine your phone reminds you to buy something when you get to the mall?

These are the functioalities:

• Voice Reminders. Now you can recorder the reminder and you even can use it as a sound for the reminder.
• Map reminders. Mark places on the map, add a text or voice reminder and when you get to these places the reminder will go off. Imagine your phone reminds you to buy something when you get to the mall?
• Custom sound. You can choose among all of the phone ringtones and whether the sound is insitent or not.
• Smart Reminders. Before this relese you had to select the date when the reminder was enabled. Now with this type, you create a reminder and the phone detects when it’s still for a while and it will be enabled, for instance:
  • You are walking home and you thing it might rain, so you create a new “smart reminder”, you name it “might rain” and  without  no more options, you put your phone back in your pocket.  The app detects that you keep walking, so the reminder is not enabled, after a while you get home, you leave your phone on the table, and the apps detects that the phone is still for while and enables the reminder, so when you are about to leave your home and pick your phone up, the reminder will be shown: “might rain”, pick an umbrella.
  • Also you can set how long the phone has to be still.

Screenshots

We can see the buttons for adding reminders and also see the stored and scheduled reminders

New Smart Remider

Press the "Smart quick reminder"

Select the kind of the reminder

Both of them let you choose the way in which the reminder is shown:

• When you get to the marked places.
• When you put your phone back in your pocket

It’s very easy and quick to add new reminder.

Voice Reminder. Record your voice like a reminder.

Text Reminder.

The “Voice Reminder” can be used as the ringtone of the reminder. If you only want the reminder to show you when you put your phone back in your pocket, that’s it.  You only have to press save.

If you want the reminder to show you when you get to the some place, then you only need 2 more steps:

Select "you get to the marked places"

The map is opened.

Press and hold whatever location you would like to place a reminder at

Click on it to edit. Touch the screen and drag left to decrease the radius and right to increase it.

Touch “Save” button and that’s it!! When you get the marked place the reminder will go off.

If something is not clear, use the Help in order to learn how tou use it.

New  Remider

The only different between “New reminder” and “Smart Reminder” it’s that you can schedule when the reminder will start and it’s more cool xDD.

Step 1	Step 2	Step 3	Step 3
The name used for managing	Select the kind of reminder	If you chose "Sound reminder"	If you chose "Text reminder"

Step 4	Step 5
You have choose how the reminder will be shown.	The First button opens the map in the same way like the "smart reminder".

Step 5	Step 5
The second button lets you to set a date in which the reminder will be enabled.	The third button lets you to set how long the reminder has to be still to be enabled

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 …

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

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.

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

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.

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.

]]> http://managementfromscratch.wordpress.com/2008/12/26/claro-que-soy-agil-por-dios/feed/ 4 jaaaelpumuki Yo después de 2 semanas de prácticas ágiles http://managementfromscratch.wordpress.com/2008/12/22/balance/ http://managementfromscratch.wordpress.com/2008/12/22/balance/#comments Mon, 22 Dec 2008 21:10:27 +0000 jaaaelpumuki http://managementfromscratch.wordpress.com/?p=68 ]]>

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

]]> http://managementfromscratch.wordpress.com/2008/12/22/balance/feed/ 2 jaaaelpumuki bad_santa_naked http://managementfromscratch.wordpress.com/2008/11/26/las-metodologias-agiles-y-el-mundo-real/ http://managementfromscratch.wordpress.com/2008/11/26/las-metodologias-agiles-y-el-mundo-real/#comments Wed, 26 Nov 2008 21:43:05 +0000 jaaaelpumuki http://managementfromscratch.wordpress.com/?p=62 ]]>

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.

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.