Velocidad, trabajo y tiempo son las tres magnitudes que mide la gestión de proyectos ágil. Las tres componen la fórmula de la velocidad, definiéndola  como cantidad de trabajo realizada en por unidad de tiempo.

Me apunto a la micro-tarea de difusión de esta iniciativa.

La fundación Bip Bip ha creado la iniciativa microvoluntarios.org, en ella puedes colaborar en tareas de corta duración elaborando informes, soporte informático y demás tareas para las ONGs de ayuda a los más necesitados. 

-¡Qué coordinación la tuya, para caminar con tantas patas, y no tropezar nunca! -dijo la hormiga al ciempiés-. Este, que nunca lo había pensado, descubrió sorprendido que, a partir de entonces, cuanto más lo analizaba, más se tropezaba.

Si te gusta la compañía de la música, y como yo, no conocías musicovery ... merece la pena echarle un vistazo. La verdad es que interfaz y usabilidad pueden serlo todo.

La nueva versión de iceScrum tiene muy buena pinta. Quizá un pelín inestable, con algún error esporádico, pero no parece nada serio y apunta ya muy buenas maneras.
Hoy es la mejor herramienta para Scrum open source que conozco, y aunque la comunicación directa y la pizarra física pueden ser la mejor opción, en equipos distribuidos, o como herramienta de registro y respaldo en la intranet de la oficina, es para tener en cuenta.

Todos somos únicos, y diferentes a los demás.

Dice una teoría sicológica (1) que la personalidad es el resultado que produce en  nosotros la mezcla de un conjunto de factores (afectotimia, inteligencia, ego, sumisión...) que cada uno combinamos en nuestro propio espectrograma.

Y con las empresas de soft me parece que pasa como con las personas: que cada una es diferente. Que de unas te puedes fiar más que de otras y que una cosa son las apariencias y otra la realidad. Por eso las primeras impresiones pueden terminar fiasco, y tras los vaqueros y el aspecto de descuidado gurú puede haber menos talento del que se aparenta, o también puede ser que el lustre de trajes y  diplomas no sea el reflejo del fondo, sino la tapa que lo oculta.

Gracias a Lucas , he tenido la suerte de poder acceder en "preview" y estrenar la plataforma que con el nombre "Open Procedures" abrirá sus puertas en las próximas semanas.
Un proyecto de difusión libre de conocimiento especializado en procedimientos. Permitirá a profesionales y autores publicar y difundirlos libremente y a toda la comunidad poder consultarlos y aportar sugerencias o participar en su desarrollo.

El look inicial de la plataforma, y de la primera versión "alfa", (ni tan siquiera me atrevo a decir beta) de una implementación Scrum se puede ver aquí
Desde ya, si queréis sugerir modificaciones o directamente acceder también como editores al modelo, no tenéis más que decirlo.

 P.D. Invitaciones para usar la plataforma en beta: info<at>nevant.com

Agrupo en un nuevo menú (sí, ese nuevo de la izquierda ) una selección de vídeos para disfrutar a demanda, de charlas, presentaciones y tutoriales como si de un seminario on-line se tratara.

Iré agregando los que se vayan publicando en Youtube, y si sabéis de alguno que se me pase...

De momento hay 2 apartados:

• Selección de vídeos sobre gestión predictiva.
• Selección de vídeos sobre gestión ágil.
  

Google, iPod o Facebook conocen bien la ecuación producto = interfaz, y saben que el mejor interfaz es el más simple, porque a los usuarios no nos gustan los programas que hacen trabajar al ratón más que un videojuego.

Esta es la idea base de la presentación del diseñador de interfaces de usuario Aza Raskin:

• Charla Don´t Make Me Click, sobre diseño de interfaz de usuario y usabilidad, en Google Talks.

A mi forma de ver, a scrum le falta un nivel de zoom, o de detalle en como trata los requisitos, por eso, definir las tareas de la pila del producto, o product backlog, se suele terciar de forma confusa.
¿Qué es cada elemento de un product backlog?: ¿una funcionalidad? ¿una historia de usuario? ¿un caso de uso?.

 Aclara bastante trabajar con tres niveles de requisitos:

1. Nivel de product manager: funcionalidades generales que quiere el cliente
2. Nivel de usuario: historias de usuario que componen cada funcionalidad
3. Nivel del equipo: tareas de programación en las que se descompone cada historia

Los podemos llamar así, si tenemos en cuenta el rol de quien emplea los requisitos a ese nivel. También se podrían llamar: nivel de producto, nivel de versión y nivel de sprint; es sólo cuestión de adoptar un criterio de nombres conocido y válido en la organización.

Por término medio, sea el oficio que sea, el salario de un "senior", es un 65% mayor que el de un "junior" (ver grafica ). En los últimos tres meses los salarios relacionados con linux han tenido un repunte mayor que la media de trabajos de programación (ver gráfica) el salario medio de un programador especializado en Java o .Net está por los 28-29.000 € anuales... son experimentos con InfoJobsTrends, la nueva herramienta de InfoJobs.

vía: tufuncion

Felicidad en el trabajo, algo que dicho así,"en seco", puede parecer más un oxímoron gratuito, que la práctica posible y recomendable para trabajar en campos de scrum. Algo que comparten más fácilmente los gestores de la teoría Y que los de la X , pero como dice Alexander Kjerulf en La hora feliz es de 9 a 5:

"Incluso si crees que el único propósito de los negocios es hacer dinero, aun así tiene que interesarte la felicidad de tus empleados, ¡sencillamente porque los estudios demuestran que unos empleados felices te harán ganar más dinero!

"... Sin embargo, en los negocios donde más se trata con la información y con el know-how, un directivo ha de enfrentarse con un nuevo problema. Aquí se desrrolla una rápida divergencia entre el poder basado en la posición y el basado en el conocimiento, lo cual sucede así porque varía con gran rapidez la base de conocimiento que constituye el fundamento del negocio.
¿Qué quiero decir?. Cuando alguien se licencia en una universidad de tipo técnico, en ese momento y durante los años siguientes, esa persona se encontrará al día respecto a la tecnología de su tiempo. Por tanto, posee un gran poder en la organización que le contrató, que se basa en el conocimiento...

Supongamos que necesitamos un método para formular el número de naranjas que caben en un volumen determinado, y que necesitamos que sea un método fiable para que una ingeniería lo pueda emplear con garantías, tanto si lo aplica con furgonetas, camiones, barcos...

Deberíamos determinar primero el volumen. También habría que tener en cuenta el tipo de naranjas, porque de una a otra variedad, el diámetro medio de la pieza cambia sustancialmente. Se podrían establecer criterios de clasificación de la mercancía en función de la variedad de la que se trate, o del porcentaje de cada una, si es una mezcla. También habrá que tener en cuenta si se carga a granel o en cajas y el tipo de estas...

Ya está disponible. Un proyecto que desbordaba el ámbito de blog de Navegápolis, que ya tiene la forma suficiente para levantar el telón y, si resulta útil, empezar a crecer.

La pregunta que escribió ayer Javier : ¿Cuánto cuesta un certificado CMMI?, junto con la de ¿dónde hay que ir? son LAS PREGUNTAS de los gestores sobre los modelos de calidad; y como dice Javier, pese a mucho googlear, no se encuentra la respuesta de forma clara.

Pues venga, vayan en este post las respuestas a las cuestiones realmente interesantes.

Parece ser que si de bases de datos se trata, es más fácil entrontrar trabajo si sabes de Oracle que de SQL Server, y a su vez más con SQL Server que con MySQL. Si de lenguajes se trata, mejor Java que .NET.

Es un experimento de lo que devuelve infojobs al pedir ofertas de trabajo que contengan:

• Oracle = 1.979
• "SQL Server" = 985
• Mysql = 558

• Java = 1.983
• .NET = 1.182

Es más una curiosidad que un dato riguroso, pero estos son los números según las ofertas publicadas en el último mes en Infojobs, realizando la consulta a las 15h. de hoy.

Algunos proyectos necesitan previsión de fechas y costes, y otros, valor constante, y ser vanguardia continua en un mercado muy rápido.

Hay una gestión de proyectos que vela por el cumplimiento de fechas y costes: que mide el trabajo, lo trocea, reparte tareas a los programadores, coordina el trabajo, vigila riesgos y controla y actúa para que se cumpla el plan.

Hay otra gestión de proyectos que vela por el valor del producto, por que los programadores sean un equipo que dé al producto lo mejor de su conocimiento, a través de la motivación, la comunicación e interacción directa.

El blog de requirements.net apunta el carácter paradójico de algunos CIOS, analizando las respuestas de una encuesta hecha a directivos de empresas TIC:

• El 75% afirma no conocer bien qué es desarrollo ágil.
• El 75% afirma estar dispuesto a implantar una metodología ágil.

Recuerdo el CEO de una firma de software, que a mi recomendación para adoptar prácticas de CMMI me respondió (absolutamente serio y convencido de lo que decía): "No, mejor ISO 9000. CMMI no es un modelo conocido, sin embargo ISO 9000 sí, y es mejor para la empresa decir que trabajamos con ISO 9000"

Algunos directores son así :-)

Dos textos en los que se habla de la madurez de las empresas: CMMI y El Principio de Peter. El primero la vende como admirable, y sin embargo el segundo la anatematiza.

Para CMMI, menos mal que las jóvenes empresas alocadas, a través del aprendizaje de su medelo, adoptan procesos-adolescentes, que con el tiempo, tras sucesivos ciclos IDEAL(1), desarrollan la capacidad que dará a la empresa la deseable madurez:  Llegará a ser sabia, y tendrá respuestas predecibles y de calidad. 

Me he encontrado con este libro de descarga libre: "Dirección de grupos y reuniones. Gestión del tiempo", escrito por Pedro Marín, Paco Aranda y Pilar Guzmán; y editado por la escuela de formación Xavier Soto.

Como curiosidad (supongo que por ser una escuela de un partido político) el libro comparte página con otros dos: El manual del príncipe, Diseño y Gestión de Campañas Electorales , y Técnicas de comunicación política. Oratoria 1, 2 y 3 .

Nada más conocerla me han entrado ganas de comprar una "TaskWatch": una pizarra blanca con un reloj. A lo mejor luego no es tan útil como parece, pero tiene buena pinta para ayudar en el desorden diario.

Se me ocurre que al ser magnética se podrían indicar con imanes las tareas diarias repetitivas, y con rotuladores ir anotando y borrando el resto. Puede ser también una manera de tomar conciencia del uso del tiempo...

• La página del producto
• Los autores

La priorización de la pila del producto (product backlog), los formatos de reuniones , y las iteraciones breves hacen que los campos de Scrum sean especialmente hostiles a las leyes de Parkinson.
Y aún más si se añade a la pila del sprint alguna tarea de "reserva" por si se hubieran  sobre-estimado los tiempos

Leyes fundamentales de Parkinson:

1ª. "El trabajo crece hasta llenar el tiempo de que se dispone para su realización".
2ª. "Los gastos aumentan hasta cubrir todos los ingresos".
3ª. "El tiempo dedicado a cualquier tema de la agenda es inversamente proporcional a su importancia".

Vía Imaginactivo, he localizado la traducción en pdf de la edición de 2000 de PMBOK (Project Management Body of Knowledge): "Guía fundamental para la gestión de proyectos")  realizada por ASERPRO LTDA,

• Guía de los fundamentos para la gestión de proyectos PMBOK 2000