jueves, 24 de octubre de 2013

SCRUM o la nueva moda de gestión de proyectos.

Sí, sí... moda.

Se que suena mal, pero a ver... todas las empresas buscan expertos en SCRUM, yo abro infojobs, (hoy) pongo en el buscador SCRUM... y....sale hasta arriba de ofertas.

Esto quiere decir que o bien SCRUM es la panacea de las soluciones de los problemas en este mundo... (creo que podría ser incluso cierto... Santa Inocencia es mi segundo nombre... jejeje) o ... quien puso el anuncio lo puso porque don importante contratador ha visto que está de moda y listos.

Si, porque quien pone el anuncio, no sabe que es SCRUM, y quien se lo ha solicitado en un alto porcentaje tampoco, pero lo quiere aprender, así que, contratemos a alguien que ya sepa...

Lo de formar Scrum Masters... como siempre que hablamos de formación... que formen otros.

Pues bien, Scrum es un método que nace de Extreme Programming, pero que no es tal (XP me refiero). En este método sale la figura del Scrum Master (vamos... un project mánager de toda la vida, pero que es capaz de sentarse uno por uno con los programadores, 10 min. por día para saber como va el proyecto, que tenía previsto hacer y está pendiente, y lo que va a hacer en el día de hoy).

Y más cosas.... pero fundamentalmente tener una visión muy concreta del proyecto día a día.

Bueno, ya tenemos una visión perfecta del proyecto... ¿y que más?

La idea es establecer periodos de trabajo uniforme para ir realizando entregas en cada una de ellas, de por ejemplo 1 mes, o dos meses. Lo que se conoce como Sprint. (je... Sprint suena a ir deprisa...)

Con las tareas que el JP (perdón Scrum Master) tiene previsto tener en este tiempo, se reúne con su equipo.. e intenta que el equipo se implique. ¿como? mediante un sencillo juego de cartas que van perfectamente numeradas ... es lo que se conoce como Scrum Poker (aunque como estamos en Spain yo lo llamo Mus Scrum)

Pero esto lo dejo para otra bonita entrada en el Blog... contar como se juega a esto...

Lo que ocurre es que Scrum... se va degradando de Sprint a Sprint... Esto lo he oido varias de veces, y es cierto... si no hemos previsto que en el Sprint N vamos a corregir, cambiar, modificar lo de algún Sprint previo, pero.. ES FALTA DE PLANIFICACION EN LOS SPRINT.

Si, como suena, una modificación, cambio etc... ES UNA TAREA MAS, por lo que si está planificada, no existe degradación. Otra cosa es que queramos hacerlo ocultando dichas acciones, porque a alguien no le interese decirlo.

Pero ¿que es lo que falla?... fácil, al establecer periodos de trabajo uniformes de entregas en uno o dos meses, a algún gurú se le habrá ocurrido decir de antemano que vamos a entregar en cada Sprint. Por supuesto sin tener en cuenta que algo que tengamos hecho en los Sprint habrá que tocar, modificar, cambiar, etc... amén de que alguna previsión no se cumpla...

Entonces surge el gran problema del siguiente Sprint, que antes de empezar, ya está comprometido, luego no hay planificación de Sprint... sino de todo el proyecto.

Esta práctica hay que desterrarla con Scrum, pero... sigue ahí,

Entonces, surge mi dilema y lo que da pie al título... si hemos planificado todo el proyecto y lo que estamos haciendo realmente es esperar (controlar) que no hay desviaciones Sprint a Sprint... lo que estamos haciendo realmente no es Scrum, sino lo que se ha hecho siempre, pero disfrazado, estamos simplemente controlando tareas.

De ahí que lo considere moda. A menos, que realmente apliquemos Scrum claro.... porque Scrum, es definitivamente una muy buena práctica, pero es otra cosa.

viernes, 18 de octubre de 2013

Gestión de Proyectos

Buenas, a todos los que quieran leer este blog

Tras varios años en que cree este blog... por fin me decido a utilizarlo. Ya saben, más vale tarde que nunca... pero el tema que se preguntarán es, ¿porqué precisamente ahora?

Pues por varias razones, la primera y fundamental... que ya sé sobre que escribir, por fin me decido a escribir sobre un tema, no sobre... no se bien que....

Y el tema, pues no podía ser otro que la gestión de proyectos, en concreto la gestión de proyectos informáticos.

Pero de esto ya hay mucho escrito... yo pretendo darles otra visión, no solo de herramientas, sino de porque no funciona correctamente la gestión de proyectos en este país, España y de paso adentrarles en las diferentes formas de gestionar un proyecto.

No hablaré de estilos de gestión solo (que también), no hablaré sólo de métodologías (que si lo haré también) sino de un compendio de ambos, de los problemas endémicos de esta nuestra sociedad empresarial y de mi queja del hasta aquí hemos llegado con la mala gestión.

Si, mala gestión en este país, que nadie quiere ver. Un amigo tras irse a trabajar a Irlanda me lo resumía...

"Si en España cobro 40.000 € brutos / año y no soy rentable... pero en Irlanda por el mismo trabajo que hago en España me pagan 60.000 € brutos / año y si soy rentable... ¿que falla sino la gestión?"

Y saben lo peor... que tiene razón... 

En Irlanda (lease fuera de España por favor...) los trabajos se realizan una vez, cada uno pone máximo desempeño en su labor, y cuando llega la tarea al programador... este sabe lo que hay que hacer. Lo hace UNA VEZ, y listos... a otra cosa...
Aquí... una vez realizada, empezamos con el... mejor cambiame ahora esto, pon otros colores a la pantalla, mueve el botón ahora ' asá ' y claro... lo que costaba 10... pasa a costar al final 25... 

No podemos ser rentables... ¿o si? Yo creo que si. Simplemente... porque lo he conseguido hacer algunas veces en este pais... si, si... en España.... pero la verdad, pocas veces (aunque con honrosas excepciones) he notado que esto haya gustado a mis superiores.

¿Será que les duele reconocer la competencia? ¿O que para tapar a alguno que no hizo su trabajo, otros hemos de apechugar?

Prefiero pensar lo último, pero en lugar de tapar... empecemos a jugar al responsabilizate de tu trabajo, lo que ha de ser válido en todos los niveles.