Category Archives: SOFTWARE

IMPLEMENTACION DE MANEJO DE EXCEPCIONES EN JAVASCRIPT

Que un programa pueda tratar con errores y condiciones desconocidas es critico en el desarrollo de cualquier software. En JavaScript también sucede, vamos a revisar las estructuras para el manejo de errores provistas para estas situaciones.

Los tradicionales Try…Catch….Finally usados también en C# y en otros lenguajes de programación, los encontramos también en JavaScript

Otra parte importante es revisar la presencia de valores nulos.

Otra buena practica es el manejo de error personalizado esto mejora la devuelta de información a los programas o librerías.

Iniciaremos con el análisis de los bloques try…catch….finally, cuando estos no están implementados simplemente el mensaje de error es tratado como una excepción no manejada, provocando que el navegador se rompa o muestre un mensaje extraño al usuario.

Tener en cuenta el ámbito que aplica en cada bloque, es decir si una variable se declara en el bloque Try no será accesible desde el Catch. La recomendación es declarar las variables por fuera de los bloques.

Comúnmente se utiliza la forma de crear excepciones personalizadas o propias, para esto, en las condiciones que se requiera, se utiliza: throw new error(id, message.toString()) esto crea la excepción a partir de los dos parámetros del objeto Error.

/* * Creates a ZipCode object. *

* Accepted formats for a zip code are:

*    12345

*    12345-6789

*    123456789

*    12345 6789

*

* If the argument passed to the ZipCode constructor does not

* conform to one of these patterns, an exception is thrown. */

function ZipCode(zip) {

zip = new String(zip);

pattern = /[0-9]{5}([- ]?[0-9]{4})?/;

if (pattern.test(zip)) {

// zip code value will be the first match in the string

this.value = zip.match(pattern)[0];

this.valueOf = function() {

return this.value      };

this.toString = function() {

return String(this.value)      };

} else {

throw new ExcepcionFormatoCodigoPostal(zip);

}

}

function ExcepcionFormatoCodigoPostal(valor)

{

this.valor = valor;   this.mensaje = “no conforme con el formato esperado de código postal”;

this.toString = function() {

return this.valor + this.mensaje   };

}
Revisar los valor nulos 

Otra forma de prevenir muchos errores es la validación de los valores nulos antes de se utilizados.

Cuando las variables nos numéricas, pero pasaron como parámetro por ejemplo a una función, pero con valor en nulo, el resultado para JavaScript en este caso sera un NaN (not a number) que es un tipo especial de JavaScript.

Tip de examen

Las propiedades del objeto excepción son mensaje, numero y nombre.

IMPLEMENTANDO SCRUM POR PRIMERA VEZ

Tantas cosas bonitas que se oyen hablar de Scrum, aclarando que no es una metodología sino un marco de trabajo, vamos a implementarlo por primera vez en una empresa. Pero cuales son los principales obstáculos que nos podemos encontrar? Vamos a explicarlos.

El escepticismo del equipo en metodología ágiles. Según lo que se conoce scrum ha funcionado en otras compañías. El equipo puede sentirse incómodo con la utilización de nueva terminología, sentirse presionado o no adaptarse a los procedimientos y eventos que se presentan. Podemos emplear una terminología adaptativa para que sin salirnos de scrum lo podamos implementar contando con un equipo con baja resistencia.

La cantidad de eventos tan seguidos y continuos. El equipo puede pensar que más reuniones son más seguimiento al trabajo y en parte es verdad, pero también el equipo que no tiene fe en scrum, puede creer que las reuniones son solo perdidas de tiempo.

Tenemos un equipo poco autogestionado. Es un requisito para las metodologías ágiles, los equipos deben ser autogestionados y autónomos, deben tomar sus propias decisiones siempre que estas decisiones los acerque mas al objetivo de cada sprint.

La infraestructura de la empresa en el área de TI. Scrum para desenvolverse requiere involucrase directamente con el usuario, tanto que es el usuario quien ordena y  prioriza las tareas de cada uno de los sprints al usuario. Esto cambia completamente la estructura de proyectos donde un usuario hace el requerimiento y al cabo de un tiempo le informan que quedo terminada su solicitud. A parte de todo, este proceso se volvió burocrático y podemos encontrar mucha resistencia de las personas que gestionan esa burocracia.

Errada definición de terminado. Esta debe ser conocido y aceptados por el equipo de proyecto. Lo que para el equipo de desarrollo esté terminado, para el dueño de producto no. La definición del criterio de aceptación debe ser muy clara para todos los miembros del equipo de desarrollo.

Seleccionar mal el dueño de producto. el dueño de producto puede cambiarse, ser originalmente alguien de TI, pero debe terminar en manos del dueño del proceso quien es quien debe maximizar el valor del producto.

Otro riesgo es la cultura, la adaptación de estas metodologías debe imprimir un fuerte cambio en la cultura. Los requerimientos se están convirtiendo en un formalismo, pero solo por cumplir, lo que el usuario quiere implementar nunca estuvo en documento alguno. El cambio más fuerte de esta metodología puede estar en la cultura. Es tal y como lo muestra el documento de Kenrik Kniberg  en el libro Culture over process. (dejo link con video)

link

Finalmente, la implementación de scrum deberá al principio intentar seguirse al pie de la letra según como menciona la guía de scrum y poco a poco adaptar lo que se requiera para conseguir resultados con este marco de trabajo.  

Desarrollo de Software hacia incremento de producto II

Definición de Producto

La metodología de desarrollo que proponemos, permite empoderar a un rol desempeñado por una única persona orientada al proceso el valor del producto.

Entregar parte del trabajo cada semana y preguntar al cliente en que quiere que trabajemos la próxima semana permite dar cierta tranquilidad y a enfocar todo el esfuerzo a un incremento de producto que el usuario va a usar, porque el sentido de pertenencia del producto le permite fácilmente implementarlo maximizando su valor.

Muchas veces pasa en las empresas que después de horas de desarrollo de un proyecto, incluso después de largas capacitaciones el usuario no utiliza el desarrollo simplemente porque lo que finalmente se implementó dista de lo que el usuario esperaba o las condiciones del negocio cambiaron y es necesario volver a generar documentos de requerimientos y otras horas de desarrollo, en ese momento el usuario opta por apartarse de apersonarse del producto y el resultado final es una opción olvidada de menú.

Siguiendo los principios de metodología ágil, nos debemos enfocar en seguir y conseguir los artefactos que se hacen presentes a lo largo del desarrollo por equipos autogestionados.

La metodología ágil tiene la ventaja de reducir la burocracia y de obtener incrementos enfocados al producto y no al proceso en sí.

Lo primero a identificar claramente  es el producto, se deben tener en cuenta los eventos que se presentan ya que metodologías como scrum basa la estructuración en Transparencia, Inspección y Adaptación. La transparencia indica que todo el equipo conoce los objetivos, la inspección es para asegurar el camino hacia el incremento del producto y la adaptación es para incluir los cambios que se presentan en el negocio y poder actuar rápido a ellos. Cualquier cambio en los requerimientos será bienvenido.

Roles de Scrum

El equipo de scrum tiene 3 roles: El dueño de Producto, Scrum Master y El equipo de desarrollo

El dueño del  producto: es una persona orientada al negocio y está responsabilizada de la pila del producto ordenando y priorizando los ítem de esta lista producto, asegurándose de que cada ítem sea lo suficientemente claro para todo el equipo scrum.

Además es quien debe maximizar el valor del trabajo del equipo scrum.

El Scrum master: Es un experto es scrum quien asesora en la metodología y se encarga de que el marco de trabajo sea seguido por el equipo scrum. Ayuda a remover los impedimentos y a facilitar los eventos de scrum.

El Equipo de desarrollo: Es el equipo de la aplicación expertos en las diferentes áreas que se encargan de generar incremento de proyecto manejando y administrando su propio esfuerzo.

Deben ser autoorganizados y multifuncionales.

Eventos de Scrum

Los eventos de scrum se desarrollan entre sprint que son bloques de tiempos que no superan un mes y que en este caso se va dar una duración de una semana y durante el cual un incremento de producto será entregable y puesto en producción.

Un Sprint es un contenedor de otros eventos. Como el sprint es de una semana, estos eventos se presentan cada semana.

Planeación del sprint: se propondrá 2 horas para preparar la lista de sprint que contiene el plan del sprint.

Reunión diaria: Reunión de 15 minutos que realiza el equipo de desarrollo para inspeccionar lo que se ha desarrollado en las últimas 24 horas y lo que se planea hacer hasta la próxima reunión.

Revisión del sprint: Reunión de 1 hora con los miembros de scrum, patrocinadores y usuarios para revisar el incremento del producto tomar retroalimentación de los usuarios que permite actualizar la descripción de los ítems en la lista de producto.

Retroespectiva del sprint: Reunión de 1 hora para tomar las lecciones aprendidas del scrum y que estas enseñanzas sean incorporadas en los próximos scrum. Los eventos están diseñados para habilitar la transparencia, la inspección, la regularidad y la adaptación.

 

 

Desarrollo de software hacia incremento de producto I

Los objetivos en el desarrollo de software deben ser medibles y claros.
Desde el comienzo, cuando se están planeando las tareas se debe tener presente el incremento que va a tener el producto. Este incremento debe ser funcional.
Si se quiere hacer un seguimiento mucho mas continuo la obtención de este incremento debería ser en ciclos cortos de dos a tres semanas.
Pero esto no significa que los requerimientos deban estar estaticos en el tiempo.
Hace un tiempo se desarrollaban productos en fases o en cascadas, primero se levantaban los requerimientos, luego se analizaban, se desarrollaban y se entregaban, muchas veces quedando un malestar en el producto final, porque se entendió mal, o sencillamente el producto obtenido de la forma que se había imaginado no se adapta a la necesidad del proceso.
Hoy en día, se están utilizando marcos de trabajos ágiles que estrechan el producto con el cliente, le permite dar un rol y le permite conocer como va evolucionando el software.
Desde la perspectiva de un marco de trabajo como Scrum, uno de los roles de los 3 que existen es el del dueño del producto. Pero no debe verse como el que va a pagar (el dueño de la chequera), es el que debe sacarle el jugo al producto. Tiene la no poca responsabilidad de tomar la decisión de pasar a producción la finalizacion de un ciclo corto de desarrollo.
El dueño del producto debe conocer muy bien los procesos y las necesidades, por lo que no debe ser seleccionado por cumplir, sera la persona que defina las características y funcionalidades que tendrá el producto final. tiene que registrar las historias de usuario, las cuales determinan el incremento del producto. Debe ser él quien maximice el producto y en sus manos está el retorno de la inversión que hace la compañía,
Define las prioridades y también es quien puede cambiar la lista conocida como product log. Es también el encargado de definir cuando un ítem de la lista esta completo y cumple con lo que se espera, en firmas que tercerizan el desarrollo de software este debe ser un usuario experto y debe trabajar mucho tiempo junto con el equipo de trabajo. En empresas que tienen software In House, el producto se define a un área especifica y esta persona encargada de esta responsabilidad deberá ser un empleado con mucha experiencia que tenga muy claro los procesos y las necesidades que se deban cubrir con el producto, así como tener la habilidad de hacer entender muy bien estas necesidades al equipo de trabajo.

Cuando las empresas construyen su propio software

 

El software tiene un proceso. Las empresas que desarrollan su propio software no pueden ignorar estos procesos. Las casas de software enfocan sus esfuerzos en aplicar certificaciones que les permita conseguir clientes, y estas certificaciones son un reconocimiento institucional de que estas empresas siguen ciertos procesos, pero las empresas que hacen su software no requieren aplicar a estas certificaciones sin que esto signifique que deban ignorar los procesos de software.
Las personas que están detrás de estos procesos también deben tener roles específicos dependiendo del marco de trabajo escogido. La persona líder es la encargada de estos procesos, debe generar una sinergia para que el equipo de trabajo consiga resultados.

Resultado de imagen para lider

Esta persona deberá tener una especialización en manejo de proyectos o en áreas afines a ingeniería de sistemas. La experiencia también es importante, escoger mal esta persona es un error muy común en las empresas. Además que es un error costoso, porque después de que fracasen algunos proyectos las empresas se dan cuenta bastante tarde de que la persona nunca utilizó procesos de software.
Una base fuerte de valores en los equipos de trabajo son necesarias para el desarrollo y fundamento de procesos ágiles de software.

Criterios de aceptación vs requerimientos

El equipo debe interpretar los requerimientos y también entender los criterios de aceptación para lograr completar los requerimientos rápidamente. Según marcos de trabajo ágiles como scrum es indispensable que exista transparencia dentro del equipo y las partes interesadas.
Uno de los valores del scrum es el respeto, en este apartado dice que cuando se trabajan juntos se comparten éxitos y fracasos en los proyectos, donde hay ayuda y compromiso con las metas. Tener las personas equivocadas lleva a que no exista relación, no exista transparencia, y se pierda el respeto en los equipos. Los resultados que se van a obtener sin duda son el continuo fracasar en los proyectos y con esto llega el actuar de Poncio Pilato  “lavarse las manos” y  esto genera que se pierda mas respeto y a su vez que se fracasen en mas proyectos, cuando la base de los problemas básicamente es confundir los requerimientos con los criterios de aceptación.
Después de que la empresa halla invertido un musculo financiero importante en este departamento intentará traer consultoría de casas de software solo porque no tenia las personas adecuadas en los cargos de gestión.

 

VELOCIDAD DE LOS EQUIPOS DE TRABAJO DE SOFTWARE II

El desarrollo de software hace parte de un proceso creativo tal como lo es el arte.

Pero también es parte fundamental en el core de negocio por lo que la tendencia es que se pretenda producir masivamente tal como producto de una fabrica de software. Por eso toma cada vez mas fuerza las certificaciones.
Un profesor de sociología que me dictaba la especialización de software nos decía que la certificación no es mas que la acreditación que otorga una entidad para validar que la persona esta en la capacidad de seguir una serie de pasos específicos y que esta persona conoce estos pasos.

Mas allá de todo esto cómo podemos medir la velocidad de como se mueve un equipo de desarrollo de software?.
Todo surge porque no se si un equipo tenga la autogestión suficiente para saber a que velocidad debe moverse en un proyecto informático.
La siguiente hipótesis es triste, pero estamos en el país que adopto dos nuevos mandamientos: “No dar papaya” y “a papaya puesta…” mientras tengamos esta cultura tan interiorizada sera un fracaso permitir que los equipos se autogestionen. Si. Es triste.
Pero no solo es cuestión de cultura. Colombia no tiene buenas universidades, esta muy lejos en los ranking mundiales y cualquier garaje gradúa ingenieros. Esto hace mas triste el panorama.
Entonces los equipos de software necesitan ser administrados pero permitiendo que pueda fluir la creatividad y al mismo tiempo siguiendo unos pasos específicos. Pero sin dar papaya y escogiendo muy bien los profesionales, porque se pueden colar en los equipos de trabajo aquellos que vienen a calentar puesto y mientras cumplen su horario laboral disfrutan de una linda película a través de los recursos de la empresa.

La literatura que encontré habla de una velocidad de crucero pero existen las 3 variables conocidas como las “p”. Procesos, proyectos y personas. Tenemos procesos?, tenemos proyecto?, tenemos la gente para esto.

Pensaba que en este blog deducir una formula mágica de distancia sobre tiempo pero en términos de software. No lo logre.

Es mucho mas complejo que eso.

VELOCIDAD DE LOS EQUIPOS DE TRABAJO DE SOFTWARE I

¿Cuánto cuesta el desarrollo de un proyecto?

La forma mas fácil de asociar los costos de un proyecto de software es basado en la duración del mismo y de los recursos que se requieren.

Es necesario tener recursos para administrar los proyectos, para establecer su calidad y obviamente para llevar a cabo su desarrollo, independientemente de la metodología o del marco de trabajo que se utilice en los proyectos, se conforman equipos para conseguir los objetivos. Finalmente un proyecto lo que consigue es cubrir un objetivo.

Por mi experiencia, le puedo decir que es mala idea empezar a remar sin saber a donde se quiere llegar, esto quiere decir que lo primero que se debe definir en un proyecto es hacia donde se debe llegar. Es curioso pero en ocasiones el cliente mismo no sabe específicamente lo que quiere y esto no esta mal, solo que dificulta la previsión de un presupuesto para el proyecto. Son esos clientes que identifican una necesidad, pero no saben exactamente como debe cubrirse, y aquí es donde es muy valorada la experiencia y el conocimiento del proceso.

En mi opinión el cliente debe hacer parte del desarrollo, muchas metodologías lo siguieren (sobre todo las agiles) y esto hace que los requerimientos sean dinámicos y variantes con el tiempo. Para que tenga éxito deben haber reuniones de seguimiento constantes.

 

Pero en este apartado estamos explorando la velocidad de los equipos de desarrollo, muchas veces lo que tenemos es un objetivo y una cantidad de tareas algunas escuetas, ahí arrumadas y unos equipos de trabajo también ahí arrumados. En algunas ocasiones con fortuna lo que tenemos es un porcentaje y unos tiempos.

La siguiente historia es verídica en un proyecto faltando semanas para la entrega se le pregunto al equipo de trabajo cual era su porcentaje de cumplimiento habiendo respondiendo que un 95% y luego faltando un día se encontraba en 97% , pero como era posible que no se fuera entregar a tiempo si unas semanas atrás solo faltaba el 5% ahora todavía falta un 3% . A lo que respondieron si, pero es que es el 5% mas difícil. Plop!

Esto me motiva a escudriñar acerca de las velocidades de los equipos de desarrollo. Yo supongo que debe haber una medible con formulas.

Construcción de Software

El software es pilar en las empresas y en los negocios y ahora con la propagación de dispositivos móviles cada vez más “inteligentes” el software es masificado y absorbido por la sociedad. Trabajar en desarrollo de software es algo creativo, reconfortarle a veces karmatico.

Es creativo porque en muchas ocasiones la construcción de software es considerada casi un arte.

Es reconfortarle porque las recompensas en muchos casos son efímeras, pero la satisfacción de haber asumido un reto da una felicidad interior importante.

Es karmatico porque en caso de que no le dedique la suficiente atención a una tarea, después ese desarrollo te pedirá y con creces, pero si lo hiciste de la forma esperada también te sabrá recompensar.

Yo he trabajado en consultoría en empresas Grandes como la Organización Terpel, Casa Editorial El Tiempo o Solidaria de Colombia, he participado de proyectos grandes y de proyectos pequeños. De proyectos muy organizados y de proyectos donde se empodera el libre albedrío y la confianza de caer en mano de un profesional. Pero siempre se llega al producto final a veces cerca, a veces lejos, de lo esperado. El producto final de la construcción de software.

En los últimos 25 años los investigadores han identificado las actividades que tienen que ver con la construcción de software:

  • La Definición del problema.
  • Desarrollo de los requerimientos.
  • Planeación de la construcción
  • Diseño arquitectónico o de alto nivel.
  • Codificación y depuración
  • Integración
  • Sistemas de pruebas (testing)
  • Mantenimiento correctivo

Cuando uno trabaja en proyectos informales ver una lista de esta puede llevarlo a pensar que esto representa una cantidad impresionante de papeleo, cuando uno trabaja en proyectos formales SABE que esta lista representa una cantidad impresionante de papeleo, el truco esta en encontrar un equilibrio. Es un error común establecer toda esta lista de cosas como programación de software.  Por lo general se puede pensar que la construcción de software solo involucra las actividades de construcción, sobre todo en proyectos informales, limitándose a las actividades de codificación y producción.

Hasta proyectos con metodología ágiles deben llevar documentación. A través de este apartado iremos profundizando cada una de las actividades señaladas de la mano de la academia y la literatura para su fin.

Recent Entries »