Criterios de terminado. Definition of done

Existen grandes problemas de comunicación en un proyecto de desarrollo de software. Eso se hace evidente cuanto mas se va avanzando en el desarrollo. Un gran problema de comunicación es no especificar ciertos matices que cada uno de los actores que intervienen en el proyecto interpretan a su manera.

Para evitar los problemas de comunicación merece la pena definir ciertos conceptos que parecen obvios pero que en realidad son muy subjetivos. El primero que hay que definir es el "Definition of done". Cuando una tarea, requisito, desarrollo, etc.. cuando algo esta terminado y se puede pasar a otra tarea? cuando le digo a mi jefe "ya esta" y el entiende lo mismo que yo? etc...

Los criterios no deben ser muy exigentes, ni complejos pero si establecer una serie de pasos que indiquen al implicado en el desarrollo que puede dar una tarea por terminada.

Por ejemplo, se le puede indicar a un programador que una tarea esta terminado cuando:

1. Has terminado en tu equipo de desarrollo local
2. Has subido todo el codigo al repositorio
3. Has compilado la aplicación con tus cambios
4. Has ejecutado la aplicación con tus cambios
5. Compruebas que la aplicación funciona correctamente con tus cambios

Puede parecer una tonteria pero merece la pena dejarlo claro, incluso escribirlo en algun lado para que el equipo siempre lo tenga presente.

Saber escuchar

Saber escuchar es una cualidad que se debe desarrollar. En general vas a tener dos situaciones en las que tienes que escuchar:

- Para gestión de subordinados: Cuando hagas una reunión de seguimiento, vayas al sitio de un trabajador, lo encuentres por el pasillo, etc...


- Para gestión de no subordinados: Cuando te reúnas con otras personas que no son de tu equipo existen ciertas consideraciones que debes de tener en cuenta:

Son personas que tienen prioridades distintas de las tuyas.
Son personas que no tiene porque hacerte caso.
Son personas que quieren algo de ti.

En ambos casos tienes que seguir la misma estrategia: Si tenéis que hablar sobre cualquier tema tu tienes que encarrilar la conversación, es decir sacar el tema a colación, pero que sea el subordinado el que hable. Que hable mas que tu. Si es muchas te das cuenta de muchas cosas: cual es su punto de vista, cual es su forma de plantear las cosas, cuales son sus inquietudes, cuales son sus valores. Ademas cosas mas practicas, cuanto mas hable mas información controlaras y podrás opinar sobre el tema del que estáis hablando con mas información y ademas cometerá fallos que podrás usar para llevar la conversación a donde te interesa.

Xcode. Desplegar una aplicación en un iPhone

No necesitas pagar la licencia de programador de de Apple para desplegar una aplicación que has programado en XCODE. Tienes que hacer tres cosas:

- En tu cuenta de apple (el apple ID). Indica que eres programador. Esto no cuesta dinero. Lo puedes hacer en el XCODE.
XCODE --> Preferences --> Accounts --> View Details  --> Create iOS developer


- En el proyecto de la aplicación indica que vas a firmar como iOS Developer . Lo puedes hacer en el XCODE

Proyecto --> Build Settings --> Code Singing identity. Indica que todos los apartados Automatic iOS Developer

- Tienes que indicar al iPhone que se fíe del certificado  de programador. Lo puedes hacer en el iPhone en Ajustes --> General --> Gestión de perfiles y dispositivos --> Aplicación del desarrollador

Participación en el diseño

Un gran problema que es conocido por cualquier desarrollador/jefe de equipo en cualquier desarrollo de software es la falta de implicación en el proyecto. La falta de implicación es mas normal en los programadores ya que no son responsables de la entrega y calidad del software.

Una buena manera de conseguir implicación por parte de los programadores es dejarles participar activamente en el diseño de la arquitectura y del marco del trabajo que se va a seguir en el desarrollo del proyecto. De sobra son conocidas las frases:

 - Si se hubiese pensado bien desde el principio.
 - Tenemos una forma de trabjar poco agil.
 - Etc..

Cuando se empiece con el proyecto, lo primero es marcar una  arquitectura y un marco de trabajo. Para decidir la arquitectura y un marco de trabajo el jefe de proyecto tiene que ser un guia, un mediador, el que tiene la ultima palabra pero no debe ser un llanero solitario. Tiene que ser el conductor de las ideas propias y de todo el equipo.

Lo ideal para que todo el equipo participe del diseño de la arquitectura y un marco de trabajo es mantener reuniones periodicas en la parte inicial del desarrollo para decidir como proceder. Si no disponemos de la posibilidad al principio de que todo el mundo participe se debe hacer en posteriores revisiones del diseño de la arquitectura y un marco de trabajo.

De esta manera, los programadores tendran un sentimiento mas posesion sobre el desarrollo y se veran mas implicados en el desarrollo ya que a nadie le gusta admitir que algo que vio bien en un momento del pasado ahora no es tan bueno.

La demora del programador

Una vez diseñada la solucion, estratificado el trabajo, hecho una planificación y repartida las tareas llega el momento en el que hay que programar. Entonces, normalmente desde el principio, llega uno de los primeros problemas; has asignado una tarea (de una semana mas o menos) a un programador y tras pasar el tiempo el programador no ha podido terminar la tarea¿que hacer?

Se puede ser proactivo para evitar que el programador incumpla el plazo. Esto significa realizar acciones como:

• Seguimiento casi diario del trabajo del programador.
• Solucionar los problemas que bloqueen al programador.   

pero siempre en una medida pequeña ya que si te lleva demasiado tiempo entonces no podrás dedicarle tiempo a otras cosas. Ademas, que si el programador se acostumbra a que alguien le resuelva los problemas mas complejos entonces no progresara.

La mejor proactividad son las tareas que estan dirigidas al grupo de programadores, no a un individuo. 

Con estas dos reflexiones se puede deducir que el programador puede empezar a incumplir plazos continuamente porque el esfuerzo que dediques de forma proactiva puede ser poco concentrado en el programador que no llegue a los plazos y si dedicas demasiado esfuerzo "puede" (no es seguro) que consigas que se cumplan los plazos pero seguramente hayas gastado demasiado esfuerzo.

¿Que hacer?

• Sacar al programador del proyecto cuando sea posible: No descartes esta posibilidad ya que puede que el problema sea que al programador no le guste el proyecto.
• Habla con el programador del problema: Si el problema no es de clara incapacidad del programador, no recomiendo hablarlo abiertamente ya que el efecto sobre el programador sera frustración. 

LUA. No te olvides de la memoria

Si desarrollas una aplicación en LUA no olvides siempre monitorizar la memoria ya que si no lo haces tu programa (que parece que funciona correctamente) te bloqueara el modulo al cabo de unas cuantas ejecuciones.

La forma de mirar la memoria es:

 print(collectgarbage("count")*1024);

Si no controlas la memoria el modulo te respondera algo como:

PANIC: unprotected error in call to Lua API (not enough memory)

Revisas el codigo alguna vez

El reducido tiempo de los proyectos (y el no saber hacerlo de otra manera) hace que las revisiones, pruebas, evaluaciones, etc.. Se centren todas en los resultados; en lo que puede hacer la aplicacion y no como esta hecha  por dentro.

Uno de los motivos por los que los programadores siempre creen hacerlo todo bien cuando terminan un desarrollo es que nadie revisa su codigo.

Se debe  gastar tiempo en revisar el codigo para comprobar:

• Se sigue el marco de trabajo.
• No se crean algoritmos grandes y complejos.
• Se hace un codigo mantenible.