Plantear el desarrollo de una tarea

En el dia a dia de un proyecto (de desarrollo de una aplicación informática) lo mas común es afrontar la implementación de una tarea.

       ej) Se esta implementando el proyecto "Portal de gestión de alumnos" y se quiere empezar con la tarea "Pagina de alta de alumnos". Una vez recogidos los requerimientos, hecha la planificación. se ha hecho el diseño, etc... (ya se tienen todos los pasos previos al desarrollo) ya podemos empezar con el desarrollo. No mas normal es tener una planificación como la siguiente:

Una tarea se divide en subtareas que se pueden o no solapar entre si. En las solapadas podemos poner a varios programadores (uno con cada tarea ques pueda solapar) y asi optimizar el tiempo de desarrollo de la tarea total.

El planificador de la tarea es el que ha decidido que la subtarea 1 y la 2 no se pueden solapar. Esta decision hay que respetarla. Pero se puede paralelizar. La respuesta es si.

Normalemente esta subtarea se asigna a un solo programdor (el principal motivo de asignar a un solo programador es que el tiempo de coordinacion y comunicacion entre programadores perjudicaria demasiado al desarrollo) pero una subtarea que tenga el suficiente tamaño (requiere tirar muchas lineas de codigo en varios ficheros disintos y en varios proyectos de codigo distintos) se puede dividir en algun momento del desarrollo (si nos hace falta) si el desarrollo se lleva a cabo de la siguiente manera:

                      ej) La subtarea "Gestion de BD de alumnos" de la tarea "Pagina de alta de alumnas" se desarrolla siguiendo estos pasos:

• DAO de alumnos
• DAO de cursos
• Negocio de alumnos
• Vista de alta

El programador empieza por "DAO de alumnos". ¿Como empezar? La forma correcta no empezar de cualquier manera si no definiendo el estilo que va seguir toda la implementación. Si el DAO tiene cuatro funciones mejor es definir un estilo de programacion que van a seguir las cuatro antes de empezar a picar de cualquier manera. Si se hace asi, en realidad no se tienen que picar las cuatro funciones antes de seguir con el siguiente paso, basta con picar una y el resto lo podria hacer otro programador si se da el caso que no se cumple con la planificación. El programador siempre podrá pasar al siguiente paso de la subtarea ya que otro programador podra terminar el paso anterior por él. Esto es lo que se puede llamar "empezar picando la viga":

Al picar la parte correspondiente de la viga de una subtarea, el programador ya puede pasar a la siguiente subtarea ya que los trozos que faltan los puede picar otro programador

Ojo, la parte de la viga no solo debe ser el ejemplo para implementar el resto de la subtarea. Ademas tiene que ser una parte que permita al programador pasar a la siguiente subtarea.

                           

El poder de las metricas

¿Como saber cuando un desarrollo va mal?

Esta pregunta es fácil de responder; si se va por detrás de lo planificado entonces "el proyecto va mal", si se hace una entrega y el software no cumple con el nivel de calidad entonces "el proyecto va mal", si las expectativas del cliente son claramente diferentes de lo que ofrece el software entonces "el proyecto va mal".

Realmente es fácil saber si un proyecto va mal. Hay muchos indicadores, hay muchas METRICAS. Las métricas son formas de medición: Son 1 o un 0, Son un SI o un NO, Son un valor entre 1 y 7, etc.. Son valores fácilmente obtenibles que dan una representación en una escala de como va el desarrollo.

Pues estas METRICAS son el principal quebradero de cabeza de los desarrolladores ya que cuando entregan un software (o parte de él) y los jefes se cabrean porque el software "no vale" usan una de estas METRICAS para darlo a entender.

Cuando un desarrollo va mal, los responsables suelen reunir a todo el equipo y la forma de enderezar el rumbo es usar frases como:

• Tenemos que probar mejor.
• Se necesita mas compromiso.
• Tenemos que dar software de mayor calidad.
• ....

Estas frases es lo que se desea y no una guia para conseguirlo y al final los desarrolladores acaban haciendo lo mismo que han estado haciendo hasta entonces y que en realidad no sirve porque "el proyecto va mal".

Y ¿cual es la solución? Puede que la solución sea la misma arma que se usa para decirles a los desarrolladores que "el proyecto va mal" . LAS METRICAS. Lo que se debe hacer es buscar el mecanismo que permita medir de forma univoca si el software implementado por un desarrollador es bueno o no lo es.

Pongo un ejemplo:

Partimos de un portal web y se le pide a un desarrollador que incluya una nueva pagina en ese portal. Entonces el programador usara su entorno de programación para desarrollar la pagina y cuando cree que la tiene terminada la entrega y listo. Esa pagina se integra al portal y cuando se entrega al cliente la pagina falla. Ya tenemos el lio.

El responsable tendria que haber puesto UN MEDIO que sirve de METRICA para que el desarrollador puede saber si su trabajo es correcto o no. Por ejemplo, el responsable puede poner un servidor de integracion continua que genera versiones del portal web todos los dias e indicarle al programador que solo se puede puede dar por terminada la pagina cuando funciona correctamente en el portal generado.

MEDIO        =>    Integracion continua.
METRICA    =>    Funciona en la version generada

Mini PC Android. Escribir en USB (Pen drive)

Hola

Si tenéis algún problema con una aplicación Android para escribir ficheros en un dispositivo conectado por USB (pen drive, disk memory, hard drive, etc..) o para descargar ficheros directamente sobre un dispositivo conectado por USB entonces lo mas seguro es que sea por un problema de permisos.

Los permisos para escribir ficheros en un USB se declaran en el fichero /system/etc/permissions/platform.xml

Localizar la etiqueta donde pone:

<permission name="WRITE_EXTERNAL_STORAGE" > 
    <group gid="sdcard_rw" />  <-- PERMISOS PARA ESCRIBIR EN DISCO DURO
</permission> 

y añade de la siguiente manera

<permission name="WRITE_EXTERNAL_STORAGE" > 
           <group gid="sdcard_rw" /> 
           <group gid="media_rw" />   <-- PERMISOS PARA ESCRIBIR EN USB
</permission> 


Si no existe WRITE_EXTERNAL_STORAGE entonces crea la etiqueta entera.

Reinicia el sistema operativo y ya debería dejarte escribir en un USB.

Para editar el fichero platform.xml solo necesitas un edictor de texto.

Para salvar los cambios necesitas entrar como root. Si tienes problemas para esto puedes usar los siguientes pasos:

1 Bajate del Play Store un emulador de terminal.
2 Ejecutalo y entra como root con el comando "su":

terminal$> su
terminal#>                       <-- Como ves has pasado de $ a #, eso es que ya eres root

3 Ahora salva el fichero platform.xml por si hay algun error y hay que volver a la version anterior

terminal#> mv /system/etc/permissions/platform.xml /system/etc/permissions/platform.xml.ori

4 Copia el fichero platform.xml con la modificación en la etiqueta WRITE_EXTERNAL_STORAGE en su lugar (supongamos que lo editaste en el directorio /sdcard/platform.xml)

terminal#> mv /sdcard/platform.xml /system/etc/permissions/platform.xml

Espero que esto os sirva.

Un saludo

El desgaste de un mal ritmo

Uno de los factores que afecta a la productividad de un programador es llevar un ritmo que no es el adecuado. Cuando un programador lleva un mal ritmo?

• Si las tareas no están claras. Si el programador no tiene clara cual es su tarea seguro que la terminara muy rápido y el resto del tiempo no sabrá que hacer.
• Si el ritmo de trabajo es pausado. Si se esta en un mantenimiento o en sistema de resolución de incidencias entonces el trabajo entra en forma de grifo (a veces son gotas y a veces son autenticas cataratas) y muy descentralizado (la tarea de hoy puede no tener nada que ver con la de mañana) pero si es un desarrollo de una aplicación entonces el programador necesita ver profundidad en su trabajo. Si a un programador se le da el primer trabajo que se le ocurra al jefe entonces el programador cogerá un mal ritmo.

Lo que hay que evitar por todos los medios es que el programador se pueda quedar desocupado. Si el programador esta desocupado empecerá a pensar cosas como ¿estoy perdiendo el tiempo? ¿Deberia hablar con el jefe? ¿..?  (seguro que esto te suena) etc.. y no estará concentrado en la tarea lo cual le hace no solo hacer la tarea mas lenta si no que estará predispuesto a hacer las cosas peor.

Es mejor bombardear al programador con curro que tenerlo haciendo cualquier cosa.

Desarrollo enmarcado

La mayor técnica de desarrollo en equipo que se usa en las empresas (no por su efectividad si no por su simplicidad) es empezar a echar líneas de código a ver lo que sale.

Si las cosas se piensan mejor, se pueden pensar una serie de directrices que deben seguir los programadores ya que “la traducción” del negocio a líneas de código se hace con una relación más o menos mecánica.

Por ejemplo, si se tiene que hacer una aplicación que guarde informes que siempre tienen tres partes bien diferenciadas entonces:

•        A ver lo que sale: Se hace la división de alto nivel del trabajo que el responsable considere oportuno (tu las ventanas, tu guardar en base de datos, tu la ventana de informe de gasto que tiene una lógica mas compleja, etc…) y cada programador se pone a la tarea. Las fronteras van a apareciendo a medida que se desarrolla y se resuelven como se puede
•         Enmarcado: Se considera todo el problema sin dividirlo y se define una base que al crecer puede dar una solución al problema. Primero se desarrolla un CORE que crea un informe base que es común y es muy configurable para poder dotar a cada informe de su forma definitiva. Cada programador parte de ese CORE para implementar su tarea.

Mucho ojo con el desarrollo enmarcado ya que conceptualmente todo es muy bonito pero los problemas de verdad (los que hacen perder tiempo o pueden tumbar una idea) aparecen siempre a bajo nivel. Se debe tener una CORE maduro antes de empezar a programar y uno de los programadores que participaron en el CORE debe de hacer uno de los informes. Esto último es importante ya que por muy bien que se piense el marco de trabajo cuando se divida el trabajo (dentro del marco) empezaran a aparecer problemas y habrá que ajustar el marco. También es importante elegir el (o los) informe que tiene que hacer el programador del CORE, tiene que ser lo mas representativo posible.

Codigo probable

Muchas veces se ha terminado una tarea y se pide que se pruebe el codigo. Que el codigo hay que probarlo es una cosa que se debe de tener en cuenta desde el principio de desarrollo. Un codigo es ”probable” cuando se puede hacer un test unitario para probarlo.

El gran problema de este axioma son las dependencias de otros sistemas. Por ejemplo, supongamos una funcion como la siguientes:

Private ManagerBD daoClientes;

Private ManagerWS webServicesClientes;

Public List buscarClientesValidos (Date inicio, Date fin) {

                List todosClientesEntreFechas  = daoClientes.buscarClientes (inicio, fin);

List resultado = new ArrayList();

for  (Cliente cliente: todosClientesEntreFechas  ){

                if (webServicesClientes.esValido (cliente))

resultado.add (cliente);

}

return resultado;

}

public void setWebServicesClientes (ManagerWS webServicesClientes){

                this. webServicesClientes = webServicesClientes;

}

public void setDaoClientes (ManagerBD daoClientes){

                this. daoClientes = daoClientes;

}

El metodo buscarClientesValidos es completamente probable ya que las dependencias a otros sistemas (BD y web services) son facilmente remplazables. En el test solo tendrias que usar los set para cambiar las instancias de ManagerBD y ManagerWS por unas que sean mocks y devuelvan lo que tu quieras.

Pero si por ejemplo tienes en el metodo algo asi

Public List buscarClientesValidos (Date inicio, Date fin) {

                List todosClientesEntreFechas  = daoClientes.buscarClientes (inicio, fin);

List resultado = new ArrayList();

for  (Cliente cliente: todosClientesEntreFechas  ){

                if (WSInstancia.esValido (cliente))

resultado.add (cliente);

}

return resultado;

}

Es decir, un metodo estatico de una clase que no tienes instanciada a nivel de clase entonces este metodo no es probable. Lo puedes hacer problable sacando la llamada a un metodo

Public List buscarClientesValidos (Date inicio, Date fin) {

                List todosClientesEntreFechas  = daoClientes.buscarClientes (inicio, fin);

List resultado = new ArrayList();

for  (Cliente cliente: todosClientesEntreFechas  ){

                if (esValido (Cliente cliente))

resultado.add (cliente);

}

return resultado;

}

Public boolean esValido (Cliente cliente){

return WSInstancia.esValido (cliente);

}

Ahora el metodo es probable de nuevo ya que solo tienes que que crear una instancia de la clase y sobreescribir el metodo esValido por un metodo que devuelva lo que tu quieras.

La clave de la validez de las pruebas es que NO HAY QUE TOCAR CODIGO del metodo que estas probando. Si has modificado una linea del codigo, aunque sea lo mas simple del mundo, tienes que volver a problarlo todo.

Otra cosas importante para probar es tener el entorno para probar preparado desde un principio. Es decir, para hacer la prueba de la clase que contenga el metodo buscarClientesValidos tienes que instanciarla y si para ello tienes que pasarle variables de iniciacion compleja entonces tienes que tenerlas preparadas desde el principio de la prueba. No puedes crear un entorno distinto para cada prueba porque perderias mucho tiempo.

Apunta las cosas

Una practica que solo un 5% de los informaticos llevan a cabo y que deberian hacer el 100% es tener algun sistema para apuntar lo que tienes que hacer, lo que estas haciendo, información que te aportan, etc.. es decir, TODO.

Ya sea una dirección IP donde esta la aplicación que tienes que usar, las tareas que te ha asignado el jefe, las claves de algun servidor, etc.. APUNTALO TODO.

Una de las cosas que peor imagen da y que va a retrasar tu crecimiento profesional es olvidar cosas (tareas, reuniones, etc..) o parte de esas cosas. Si las olvidas por completo da la impresión de que no te importa y si haces peor las cosas por olvidar partes de esas cosas entoces da la impresión de ser incompetente.

Tienes que elegir una manera de notación de tal manera que tampoco te lleve mucho tiempo anotar cosas y acceder posteriormente a ellas.

Si el sistema es digital (una pagina web por ejemplo) tendras mas dinamismo a la hora de modificar/ampliar la informacion y a la hora de mostrarle ha alguien la información. Yo te recomiendo  la aplicación mediawiki. (Consejo para la mediawiki: si quieres que solo un usuario registrado pueda modificar los apartados entonces incluye en el fichero de localsettings.php la linea $wgGroupPermissions['*']['edit'] = false;).

Apuntarlo todo tambien es muy util cuando un desarrollo se termina y aparecen tareas que no se tienen en cuenta al principio:

-          Poner comentarios en codigo.

-          Hacer un informe resumen a algun jefe de lo que se ha hecho.

-          Comentar un alguna aplicación de control de tareas lo que se ha hecho.

-          Etc..

Si tienes apuntado lo que has ido haciendo y como lo has hecho entonces te evitaras el problema de recorda como has hecho unas cosas e incluso de tener que escribir nada ya que puedes resolver las tareas anteriores copiando lo que has ido escribiendo. Como mucho tendras que escribir texto para darle algo de forma pero poco mas.