Author Archives: jsuarezmedina

PENSAR EN GRANDE

Scrum trae consigo una nueva forma de pensar. Yo encontraría una faceta en el hecho de que hay que pensar en grande.
Los proyectos se atascan, se bloquean. Scrum no es la fórmula mágica para destrabarlos hay que trabajar. Trabajar continuamente. Hay que pensar en grande.
Nuestra ciudad tiene ese problema, nuestros gobernantes no les gusta pensar en grande para las ciudades, prefieren un Transmilenio que un Metro porque es más barato, luego prefieren un metro elevado a un metro subterráneo porque es más barato. Seleccionando lo más barato solo llegan a soluciones que se vuelven obsoletas muy rápidamente, que muy pronto bordan su capacidad.
Yo me niego a creer que hacer siempre lo más barato esté en nuestro ADN de colombiano.
Tenemos que pensar en grande, en proyectos que puedan cumplir con el mínimo desperdicio. En soluciones que entreguen un valor agregado al cliente. En un equipo entregando productos con calidad, en motivadores que puedan sacar lo mejor de los equipos.
Pensar en grande nos va a permitir es retribuir a la sociedad, y esta nos devolverá con creces a nuestra generación o a la siguiente.
Pensar en grande puede llegar a ser lo mas costoso, pero es la forma en que deberíamos hacer las cosas en los proyectos y en la vida diaria.

EL TIEMPO ES FINITO Y TODOS SABEN TODO

¿Porque fracasan los proyectos de Software? ¿Porque los equipos formados para lograr un objetivo nunca llegan a cumplirlo?

Estos eventos ocurren en todas las compañías, sean casas de software o no y no ocurre desde ahora, ocurre desde siempre.

Jim Coplien conocido como cope “El capi” miembro de scrum Alliance fundador del proyecto Pasteur Organizational Patterns, a principios de los 90 estuvo analizando un producto de Borland Software Corparation llamado Quattro pro para Windows.

Allí hacían una reunión diaria con el fin alrededor de retos, esta se efectuaba a la misma hora y debía estar asistir el equipo.

Jim Coplien represento gráficamente los flujos de comunicación al interior del equipo, donde la información fluye y donde no, quien habla con quien. Pudo establecer una relación entre cuando más saben todos de todo más rápido es el equipo.

La reunión diaria permite eso, que todos sepan todo, no debería ser un informe personal de lo que hizo cada una de las personas del equipo, debería ser algo como tengo tal inconveniente para resolver esto y alguien en el equipo tiene la fórmula para resolverlo.

Es difícil establecer porque fracasan los proyectos de software, pero deben explorarse las opciones de hacer las cosas diferentes, cambiar la perspectiva. A veces se establece un alcance y lo que varía es el tiempo y el presupuesto. ¿Pero si se fija el tiempo y lo que se hace variable es el alcance?

El tiempo es finito, debe ser entendido como algo fundamentalmente cíclico.

En Scrum los equipos de trabajo se reúnen diariamente, pero también se trabaja en ciclos semanales de avances, se establecen sprints en los que se entregan productos funcionales. En scrum el tiempo es finito y su administración se llama Eventos.

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.

TAN CERCA DE LA BARRERA

Este año 2017 fue protagonista la empresa NIKE en su campaña BREAKING2 que consistía en una cruzada por romper la barrera de las 2 horas de marathon con sus atletas Eliud Kipchoge, Lelisa Desisa y Zersenay Tadese a traves de la ciencia e innovacion de su calzado deportivo.

El pasado 6 de mayo el keniano Eliud Kipchoge quien es campeon olimpico marcó en los cronos en 2H:00 :25 segundos. Estuvo a solo 25 segundos de bajar el tiempo. Esto se realizo en el circuito de Monza, aquella pista de formula 1 donde de disputa el gran premio de Italia.

El ritmo que da este tiempo es de 2:50 por kilometro

Nike diseño una carrera de laboratorio donde hasta 30 Pacers entraban por turnos en carrera, realizaban formacion de flecha compensando la resistencia del aire, ademas un vehiculo ofrecia rebufo e irradiaba una linea verde que indicaba la velocidad requerida.

El calzado deportivo con el que Nike doto a los corredores se llama Zoom VaporFly Elite, un calzado bastante ligero aprovicionado de una plantilla de fibra de carbono.

De todas formas este record no puede ser homologado por la IAAF debido a todas las asistencias tecnicas proporcionadas.

“El récord del mundo continúa en poder del keniano Dennis Kipruto Kimetto, que el 28 de septiembre de 2014 venció en Berlín con un tiempo de 2h02:57, pero Kipchoge, segundo del ránking oficial de todos los tiempos con 2h03:05, ha rozado en Monza los límites del ser humano en la carrera más larga del programa olímpico, alimentando el debate sobre cuánto tiempo habrá de transcurrir para que caiga el muro de las dos horas. ”  fuente: José Antonio Diego el Heraldo.es

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.

« Older Entries