Category Archives: SOFTWARE

EL INTERIOR DE LOS EQUIPOS

Cuando iniciaba mi vida laboral en tecnología, aun no me había graduado como profesional, y no me había despojado tampoco de una estúpida arrogancia que poseíamos los seres de nuestro tipo en esa época. Trabajaba, en una pequeña empresa de menos de 20 empleados y me llenaba de poder cuando recorría los pasillos de la oficina avisando a todos que debían reiniciar sus sistemas ya que se había realizado una actualización. Debian salir de esa pantalla oscura en la que estaban construidos las aplicaciones comerciales de aquella época y volver a arrancar el sistema.

Eso me daba la sensación de poder. Sentía que debía reflejar una sensación de confusión mas allá de que a nadie podría develar los misterios, algo oscuro se esconde detrás, era el guardián de los designios y todo en cuanto a información se requiriese debía consultarse al oráculo.

Y ni hablar del lenguaje técnico que empleaba para expresarme de mi trabajo, la idea era confundirlos a todos, por supuesto años después maduré, encontraba en los sistemas la manera de brindar a las gerencias la información que los llevaría tomar decisiones para alcanzar nuevos niveles.

Esta maduración llego después de años de más estudio, postgrados, reflexiones y lecturas consagradas.

En aseguradora Colpatria me encontré ya después de muchos años, con un profesional que aún no había superado estas ínfulas.  Como compañero de trabajo era realmente despreciable, era de los que utilizaba una propiedad conocida en SQLServer como KILL que se encargada de matar los procesos de todos los demás compañeros con la intensión de cargar todos los recursos del servidor solo para él. Pero cumplía con sus tareas individuales que le eran asignadas y en el tiempo previsto. Solo él, porque el equipo de desarrollo que lo acompañaba tendríamos que rehacer nuestro trabajo porque el proceso que ejecutábamos había sido víctima de uno de sus KILL.

Fue una experiencia con un equipo difícil, no había empatía, existía chismes, mentiras, confrontaciones, con un proyecto fácil de implementar, pero difícil de superar. El equipo estaba dividido social y funcionalmente en subequipos trabajando todos en objetivos cruzados que interferían a otras personas en el equipo.

Los administradores del proyecto decidieron hacer evaluaciones personales como una forma para premiar e incentivar a los mejores miembros del equipo buscando una forma para terminar la implementación del proyecto.

En su Libro “La jugada de mi vida” Andrés Iniesta escribe: “Los títulos son síntomas de salud colectiva, los trofeos individuales encienden el ego, inflaman la vanidad, son Peligrosos” esto aplicado a los equipos de desarrollo es algo así como “No premies al individuo, premia al equipo”

Esto es cierto en el interior de los equipos que desarrollan software solo debe haber un objetivo común: un producto que es el destino al que deben llegar todos, no es posible que sean equipos homogéneos, van a hacer equipos multifuncionales, tienen que ser equipos con reglas muy definidas, pero sobre todo con objetivos claros y comunes.

La implementación duro más de lo esperado, se finalizó terminando con un equipo hecho trizas.

 

Lo más difícil en un equipo son las interrelaciones personales, hay personas a las que esto se les da muy bien, otras a las que se le dificulta. Por eso si los equipos son pequeños es posible limitar los posibles roces. Fíjense que scrum define equipos de 5 a 9 personas, y scrum funciona porque trabaja sobre equipos eficientes. Este rango de numero debe tener una base empírica de que asi funciona.

Scrum pide que los equipos sean reducidos.

COMO HACEN SOFTWARE LAS EMPRESAS

El desarrollo de software ha sido un negocio lucrativo, el gran problema ha sido la forma en que se hacen las cosas. Meses de planeación y definiciones, levantamiento de requerimientos, todo para que al final los proyectos sobrepasaran los presupuestos y los tiempos.

Encontré en una lectura de Jeff Sutherland, como él asesoraba el desarrollo de software en BellSouth, una empresa con ingenieros desarrolladores de primera línea quienes ejecutaban el método cascada a la perfección:

Reunían todos los requisitos del cliente, se ausentaban 18 meses y entregaban dentro del tiempo esperado y con los requerimientos que el cliente precisamente había solicitado, solo que el cliente ya no necesitaba lo que estaba en el requerimiento, las condiciones del mercado habían cambiado, los clientes demandaban servicios con otra capacidad de respuesta, las necesidades iniciales habían cambiado.

La forma que tenían de hacer software, aunque daba la impresión de que todo se hacía bien, no estaba dando resultados, por eso llamaron a Jeff a la consultoría. Ellos tenían el problema que no existía sensibilidad hacia el cliente, no basta con escucharlo solo al principio del levantamiento de los requerimientos, era necesario vincularlo y empoderarlo en el proceso de construcción de su producto. Jeff les recomendó el marco de trabajo de Scrum. Era el camino para cambiar las cosas o estarían perdidos.

No entendieron el concepto, hacían Software no solo de la manera esperada, lo hacían bien, ¿por que cambiarlo entonces?

Aunque en el desarrollo de software Bellsouth lo hacía como pocas empresas en ese momento, Bellsouth desapareció.

Así es como trabajan las empresas, a veces con una terquedad que aterra. Equivocados, pero decididos.

Las empresas de desarrollo de software no se están fijando en el personal como un equipo, sino como individuos por separados, muchas de ellas intentan medir el desempeño personal, para evaluar la bonificación, los aumentos de sueldo o premios.

En términos de la productividad estas empresas no están obteniendo mucho beneficio, más que el software, en otros tiempos considerado como una obra más de arte que ingenieril, necesita que sea apoyado en un equipo de trabajo. Scrum le apunta al trabajo en equipo. En centrar los objetivos para todos los miembros de un equipo a obtener pronto los resultados.

Tener un “indicador” para cada miembro del equipo y no para el equipo es una práctica tan obsoleta y tan desfasada de los propósitos de metodologías agiles que se deberían desmontar.

Los equipos se depuran, esto es cuando se trabajan en equipo, con objetivos claros, la misma presión del grupo hace que los que llegan tarde o que llegan a ver videos o películas al trabajo, a dormir o a cualquier actividad que no le aporte al mismo equipo, se dispongan a aportar más. Esto sin la necesidad de un jefe, es realmente sorprendente, los efectos del equipo sobre los integrantes del mismo.

Los equipos son los que desarrollan los productos.

De otro lado, cuando no hay equipo los individuos son islas independientes, y si a esto le agregas un indicador de cumplimiento, probablemente tendrás el indicador como un número muerto, muy bueno tal vez pero lejos de un verdadero valor del producto.

SCRUM EN COMPAÑÍAS QUE NO SON IT

El marco de trabajo scrum une a equipos para crear grandes cosas, equipos concentrados en una meta, equipos comprometidos con su cumplimiento.

Lo que sucede en las empresas grandes que no son de IT es que están conformadas por áreas autónomas inmersas en procesos que algunas veces requieren de integración con las otras áreas.

Trabajan en formas que ellas mismas saben que son ineficientes y deprimentes solo por el hecho de que así lo hacen todos.

Iniciar proyectos de software en este tipo de compañía requerirá que los miembros sobrepasen las áreas a las que pertenecen y enfoquen los esfuerzos a conseguir la meta. Adoptar esto en las empresas grandes es complicado, y es la causa de los fracasos en los desarrollos de los proyectos. Es muy común escuchar cuando las cosas no marchan bien: “No es asunto mío, yo ya hice mi parte”.

Scrum promete resolver esto, es más, está llegando a revolucionar la forma como se hacen las cosas.

Scrum debe permitir evitar el desperdicio de horas en el desarrollo de software de cosas que poco aportan valor al negocio.

Una cita que encontré en el libro de “Scrum: el arte de hacer el doble de trabajo en la mitad de tiempo” de Jeff Sutherland dice:

“Aferrarse a la antigua manera de hacer las cosas, de mando y control y rígida predictibilidad, conduce al fracaso.”

“La antigua manera de hacer las cosas” es realizar una gran diagramación esmerada en imponente graficas de Gantt, con estimaciones de costos y tiempos, en hermosos colores que permitieran confundir el trasfondo de que todo lo que hay allí simplemente es mentira.

Es cierto, muchas veces nos encontramos en las compañías con trabajo realizado que no produce un valor verdadero. Obtener una pronta retroalimentación del usuario nos permitirá eliminar esfuerzos que son inútiles.

Los principales obstáculos que debe vencer una empresa que quiera explorar en el uso e implementación de scrum muchas veces provienen de la misma estructura organizacional.

Según Ken Schwaber en su libro “Scrum Development process”: las compañías que adoptan este proceso(scrum) suelen ver beneficios inmediatos.

ALGO DE SCRUM SUELTICO II

Algunas preguntas sobre SCRUM

Utiliza una frase que mejor describa el SPRINT REVIEW

“Es cuando el Equipo SCRUM y los Stakeholders inspeccionan el resultado del Sprint y los datos para los próximos.”

 

¿Cuál es la principal razón para que el Scrum Master asista a las reunión diaria del Sprint?  “El Scrum Master no debe estar allí, solo tiene que asegurarse que la reunión diaria se realice.”

 

Utiliza una frase que mejor describa la responsabilidad del Product Owner

“Optimizar el valor del trabajo que el equipo de desarrollo realiza.”

 

El equipo de desarrollo deberá tener la capacidad para convertir los elementos del Product Backlog para seleccionarlos dentro de un incremento de la funcionalidad del producto.

El Equipo de Desarrollo está formado por profesionales que realizan el trabajo de entregar una Incremento del producto “DONE” al final de cada Sprint. Los Equipos de Desarrollo son interfuncionales, con todas las habilidades como equipo necesario para crear un incremento de producto.

 

¿Quien es el SCRUM Team?

El Scrum Master.

El Product Owner.

El Equipo de desarrollo.

El Equipo de Scrum está formado por el Scrum Master (gestiona el proceso), el Product Owner (decide qué hacer) y el Equipo de Desarrollo (hace el trabajo).

ALGO DE SCRUM SUELTICO I

Algunas preguntas sobre SCRUM

¿Cuándo muchos equipos de desarrollo están trabajando en un solo producto, cual es la mejor definición de “DONE”?

Todos los equipos deben tener una definición de “DONE” que haga su trabajo combinado potencialmente liberable.

Scrum requiere un incremento de producto para ser liberable. Se espera que los equipos que trabajan en un simple producto entreguen ese incremento.

 

El equipo de desarrollo no debería ser interrumpido durante el Sprint. La meta del sprint debe mantenerse intacta. Se deben crear condiciones para fomentar la creatividad, calidad y productividad. Basado en esto, describa algunas de las sentencias de modificar el sprint

El Backlog del sprint debe estar completamente formulado en el Sprint Planning y no puede cambiarse durante el sprint.

El sprint Backlog hace visible todo el trabajo que el equipo de desarrollo identifica como necesario para cumplir las metas del sprint. Pensar que el equipo en compañía del product owner pueden modificar, remover o agregar trabajo si tiene más o menos capacidad de la que esperan es equivocado.

Descomponer un ítem product backlog puede hacer que el sprint backlog sufra cambios tampoco es válido.

Cuanto trabajo debe hacer un equipo de desarrollo para que un ítem del product backlog se seleccione para un SPRINT

Si piensas que es tanto como le pueda fijarse en un sprint estas equivocado, la respuesta es tanto como el product owner diga que será terminado para cada uno de los ítems backlog que se seleccionaron conforme a la definición de terminado.

El propósito de cada sprint es tener un incremento entregable de potencial funcionabilidad, que se apegue a la definición de “DONE”

 

Escriba una frase que de Scrum y los StakeHolders inspeccionan la finalización de un sprint y analizan el panorama de la próxima. Es una oportunidad para Inspeccionar y adaptar.

Algo mas de Funciones Callback usando JavaScript

Una pregunta acerca de la implementación de funciones Callback me salió en el examen de certificación. voy a compartirlo en esta entrada.

 

Pregunta

Estas implementando una función callback usando JavaScript. Necesitas procesar el retorno de datos XML.

Como debería completar el siguiente codigo

 

<script>

function getStatus(url, callack){

var httpRequest = new XMLHttpRequest();

httpRequest.onreadystatehange = function(){

if(httpRequest.readyState===4

&& httpRequest.satus ===200 ) {

Target1

}

};

httpRequest.open(‘GET’, url);

httpRequest.send();

}

function start(url) {

getStatus(url, function() {

Target2

});

}

</script>

 

Target1:

a) callback.call(httpRequest);

b) httpRequest.setRequestHeader();

c) callback.call(httpRequest.responseXML);

d) callback = httpRequest.getResponseHeader();

 

Target2:

a) processResults(this);

b) processResults(url.calback);

c) processResults(this.XMLHttpRequest());
d) processResults(url.callback.responseXML);

 

y la respuesta es:

para Target1 c)

para Target2 a)

 

Apuntes de Administracion de Proyectos Software

Rara vez escribo sobre administración de Proyectos, no solo porque me parece un tema muy denso, sino también porque pensaba que toda teoría de administración al momento de llevarla a la practica se caía por el contexto y la cultura que tuviera la empresa.

Pensaba: “Suena muy bonito, pero pago por ver quien lo implementa en X organización”.

Ahora pienso diferente, porque toda esa teoría de administración de proyectos no vienen aisladas de un Marco de Trabajo. El Marco de Trabajo te dicta los pasos que debes realizar en la ejecución. El resto es observación e inspección del riesgo y control.

El primero de los errores en los que se cae en la administración de proyectos de software es quedar atrapado en un diseño técnico demasiado detallado, queriendo cubrir cada uno de los aspectos mínimos de un proyecto.

La especificación de diseño, sin embargo debe estar carente de toda ambigüedad, es decir debe impedir que alguien entienda diferente a otra persona en el proyecto.

Técnicas como descomposiciones de alto valor, permite acercar mas la estimación de costos y de tiempo a los stakeholders del proyecto.

Lo que todo proyecto busca en estos tiempos es mostrar resultados en corto tiempo, por eso se embarcan mucho en las metodologías ágiles, producen los resultados muy visibles a corto plazo, pero también exige a los administradores de proyecto a tener un equipo de muy alto rendimiento que debe tener la motivación correcta para poder dar con ese rendimiento.

Lo realmente complejo es que la motivación es diferente por cada uno de los miembros del equipo y que no siempre la motivación es económica, saber identificarlas es una habilidad de los lideres de proyectos.

Lo que sé de la motivación es que generan una acción, y que existen Intrínsecas, Extrínsecas, contributivas e Institucionales . Pero ya profundizar en cada una de ellas se lo dejo a los especialistas en la materia.

La competencia del que mas grite le hace mucho daño a los equipos de trabajo, al igual que el juego de manitas calientes en las organizaciones. ¿Recuerdan ese juego donde colocabas tus manos encima de las manos de otro amigo y se trataba de estar atento porque lo que iba a intentar es pegarte palmadas en las manos que teníamos puestas?.

Bueno esa practica en las organizaciones se aplica cuando existe un rol del personaje pendiente de buscar quienes se equivocan, un cazador de brujas de esos de tiempos de la inquisición,  entonces,  te distraes y  hacen el mayor escándalo posible para que tengas tu reprimenda, sin que lo importante sea resolver el problema sino que todo el mundo alrededor del proyecto tenga la conciencia de que hubo un error de parte tuya.

Dicen por los pasillos: “oh entonces la leyenda es cierta, es un humano”.

Esto no solo rompe los equipos de trabajo sino que le quita toda motivacion a los miembros de equipo.

Usando iFrames

Los iFrame presentan la fragilidad de poder ser atacados. El atributo sandbox debe utilizarse para restringir que datos pueden colocarse en un iFrame.

El atributo sandbox puede tener los siguientes valores posibles:

“” aplica todas las restricciones.

allow-same-origin

allow-top-navigation

allow-forms

allow-script

 

OBJETO XMLHttpRequest

Consideraciones que se deben tener en cuenta para usar el objeto XMLHttpRequest.

JavaScript provee este objeto para el manejo de datos, esto es a través de un webservices , REST API o algún proveedor de servicio de datos.

El formato de este objeto es XML y sus eventos son soportados Sincrónica y Asincrónicamente.

 

Enunciare los eventos:

Onreadystatechange

Ontimeout

 

Enunciare los Métodos:

Abort

getAllResponseHeaders

Send

setRequestHeader

Open

 

Enunciare algunas propiedades, basadas en algunas preguntas que encontré por ahí para el examen 70-480

Status

readyState

Response

responseText

 

Un ejemplo típico de Open es

Var xReq = new XMLHttpRequest();

xReq.Open(“GET”, “myXMLData.xml”, false);

xReq.send(null);

 

para tener en cuenta el método Open no hace ninguna solicitud al servidor. Cuando las credenciales son pasadas al servidor el únicamente responde con un código 401 respuesta de seguridad del servidor.

if (xReq.readyState == 4  ){

 if (xReq.status == “200”){

                $(“#results”).text(xReq.response);

} else {

$(“#results”).text(xReq.response);

}

}

 

Esta puede ser el contenido de una función que devuelva el cambio de estado

El 4 significa que la solicitud está completa, se coloca en el readyState

El 200 que el estado de la solicitud es exitoso y entonces se podrán procesar los datos.

USANDO WEB WORKER API

Los web workers son utilizados para desarrollar aplicaciones multihilos en JavaScripts.

JavaScript es un ambiente mono – hilo, cada ejecución en JavaScript es encolada para ejecutarse sincrónicamente. Esto puede que no se note, pues la mayoría de las aplicaciones requiere una potencia de procesamiento no muy exigente en los equipos clientes.

El API Web Worker permite especificar que parte de trabajo debería ser procesada en su propio hilo. Esto tiene sus ventajas y sus desventajas.

El Api de Web Worker API esta basado en el FrameWork messaging de JavaScript. Esta disponible desde el global namespace y se crea de la siguiente manera.

 

Var webWorker =  new Worker(“workercode.js”)

 

Funcionalidades soportadas

 

Método Descripción
postMessage Inicia el proceso worker. Espera un simple parametron que contiene los datos para pasar al hilo. Se puede suministrar una cadena vacia
terminate Detiene el proceso worker
onmessage Especifica la function para el hilo de worker
onerror Especifica una función para el manejo de respuestas con error.

 

webWorker.postMessage(“ ”);

 

webWorker.terminate();

 

Despues que el Worker complete el proceso y los resultados necesitan ser procesados, la funcion onmessage es llamada desde el Worker.

 

webWorker.onmessage = function(ent){…}

 

En alguna parte donde el resultado debe devolverse a la aplicacion se utiliza el metodo postMessage

 

onmessage = function(e){

self.postMessage(result);

}

 

Note que se utiliza la keyword self esto es debido a que el worker corre en su propio contexto.

Desventajas de los web Workers

Parametros

El método acepta un parámetro para pasar datos al worker, este parámetro es string y puede ser serializable con objetos nativos como Objetos JSON o XML. No puede ser una función.

 

Numero de Workers

Aunque no existe un limite de cuantos workers se pueden utilizar  o crear al mismo tiempo, el numero de trabajadores es algo a lo que hay que prestar atención.

La creación de Worker es pesada, cada Worker crea un hilo al nivel del sistema operativo y esto debería manejarse adecuadamente.

Acceso DOM

Los workers operan en su propio contexto global, significa que no tienen acceso al DOM de la página que los invoca. El DOM no puede ser manipulado desde un proceso Worker.

Tampoco tienen acceso a objetos Windows, document o cualquier objeto padre.

Subworker

Un Worker puede crear otros workers. Sin embargo conocer el total de subworker que deben ser creados se vuelve muy importante.

Configuración de tiempos e intervalos.

Es posible especificar un intervalo en el background usando los métodos setTimeout or setInterval.

 

Var work = new Worker(“workerFile.js”);

setTimeout( function() {

work.postMessage(“ “);

}, 3000);

Este proceso corre despues de 3 segundos

 

Var work = new Worker(“workerFile.js”);

setInterval( function() {

work.postMessage(“ “);

}, 3000);

Este proceso corre cada 3 segundos.

 

« Older Entries