Mi PlayList para la MMB

Mi Play list para la media maraton de Bogota #MMB 2016

Estaba buscando correr con una música motivante que me impulse en esos tramos difíciles.

Reuní dos horas y ventiocho minutos de música rock, de diferentes estilos y diferentes épocas.

Hay mucha música de artistas colombianos: Los de Adentro, 1280 Almas, Estados Alterados, El sie7e, Diamante Eléctrico, La derecha o THE junto con otros artistas no tan conocidos como Ultrageno o Skampida.

También coloque canciones clásicas como “You Could be mine” de GNR o “Aces High” de Iron Maiden. Clasicos del indie The Strokes, AFI, Papa Roach. Canciones que hacen clásicos de siempre Red Hot Chillie Pepers o Limp Bizkit, Korn

Acá dejo la lista para su deleite.

JULIO MES DE LA MMB

Empezó Julio, la carrera de la media maratón de Bogotá es en este mes.

La estoy esperando con ansias. Mis entrenamientos se han vuelto mas constantes, mis tiempos han bajado y se ha contagiado una energía muy sabrosa entre mis compañeros de trabajo entorno al día de la carrera, estamos entrenando en conjunto, tenemos diferentes ritmos pero estamos muy motivados.

Además ya configuré el calzado con el que voy a correr. Esto no lo había hecho antes. Aunque mi calzado deportivo viene en incremento en cuanto a exigencia es la primera vez que tengo unos tenis un poco mas de gama media. Son unos New Balance que se sienten excelentes.

NewBalance

Acá dejo el análisis realizado por especialistas para estas zapatillas.

Analisis de New Balance Vazee Pace

Mi meta este año es hacer 2:03 en 21km

 

 

 

CUANDO LA RUTA TE LLAMA

1051
En octubre de 2012  me fui hasta la siempre hermosa Villa de Leyva (Boyacá) a correr la prueba local.
Se llamaba “Corre Villa de Leyva” con modalidades de 10K y 21K
Yo participe en la edición de 10K
Fui con mi esposa y mi hija, nos fuimos desde el sábado con la ilusión de disfrutar un magnifico fin de semana en la mágica ciudad.
Nos hospedamos en un hotel bonito y realmente disfrutamos ese fin de semana. Fue algo muy especial.
Ya para el evento, se podía notar la improvisación, la persona encargada del calentamiento no asistió y el instructor sacado a última hora nos hizo la rutina.
Fue la peor carrera que he corrido de todas: Uno porque no conocía el recorrido, había una parte que era atravesando desierto. Dos porque no había puntos de hidratación. En un desierto bajo el agobiante sol y sin hidratación… ufff. Tres porque creo que el calentamiento fue de tanto despropósito que quede agotado antes de empezar. Fue muy difícil para mi, fueron los 10 km mas eternos de mi vida.
Finalmente llegue, las manos me temblaban cuando recibía mi medalla, que quedo para el recuerdo.
IMG_20160523_192548
Ya en el 2015 para la fecha volvimos a Villa de Leyva, pero esta vez no iba a participar. Llegamos con mi familia el día domingo solo pretendíamos pasear y vivir la fiesta de una carrera desde el otro lado. Desayuné un caldo con costilla y nos fuimos a mirar la carrera.
IMG_20151018_114056
En cuanto llegue a la meta algo extraño paso, hacia calor, acababa de desayunar y que desayuno!!! pero la intriga me hizo llegar a la zona de partida. Todavía este año se notaba mucha improvisación por parte de los organizadores.
Pero algo raro pasaba. Era como si la ruta me llamara. Mis piernas empezaron a correr y de repente ya estaba participando en la carrera. hice el circuito de 10 km
1041 1045
pero esta vez el plan era disfrutar el paisaje, repasar los caminos del año anterior que me pesaron tanto e incluso estaba dispuesto a no recibir hidratación por que este año no era un participante. Solo estaba disfrutando.
1051 1042
El equipo de la organización me dio hidratación y hasta se ofrecieron para tomarme una foto, llevaba la camiseta de la carrera del año anterior, no llevaba número, pero eso no impidió que fueran muy amables conmigo.
Disfrute el paisaje, la vegetación, la atención de la gente. Fue esta edición de las carreras que mas he disfrutado ya que no estaba compitiendo contra mi mismo, ni contra nadie. Solo estaba atendiendo el llamado de la ruta cuando llama.
1052

IMPLEMENTANDO SCRUM POR PRIMERA VEZ

IMG_20151220_115012

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

IMG_0437

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

Hisilicon Balong
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

178

 

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.

 

« Older Entries