FVE Project Manager es una adaptación del programa libre para gestión de proyectos: dotProject realizada con licencia GPLv3 como proyecto de fin de carrera en de la Universidad Complutense de Madrid por Ignacio Estirado, Íñigo Fábregas y Alejando Vilella.

Es muy reciente. No lo he probado, pero como el mismo Ignacio comenta, de momento está programado como una modificación de dotProject, y está previsto que más adelante se pueda instalar como una extensión.
FVE integra en dotProject suvbersion para agrupar en una única herramienta la gestión del proyecto y de la configuración, para el control de las versiones; y permite importar descripciones de procesos en ficheros XML con formato EPF , y en esta versión ya integra la información relativa a roles, productos de trabajo, plantillas, tareas y relaciones entre ellas.

• Página del proyecto
• Manual
• Tutoriales
• Descarga

Si hubiera que determinar cuál es el origen de la gestión ágil de proyectos, a falta de mejor información, habría que situarlo en las prácticas adoptadas en los 80 por empresas como Honda, 3M, Canon, Fuji, Nec, Xerox, hp o Epson para el desarrollo de nuevos productos

La industria del software ha sido la primera en seguir su adopción, y muchos de sus profesionales han documentado y propagado las formas particulares con las que han incorporado los principios de la agildad en sus equipos de trabajo.
De esta forma han aparecido en la última década los nombres:

Los programadores tienen alrededor, quizá demasiados "jefes": el director de la compañía, el de márketing, el gestor del proyecto, el scrummaster "cinturón negro", el propietario del producto, el director técnico, el director de calidad...

¿Cuántos son necesarios?, ¿Qué habilidades tienen que tener?, ¿qué es lo que se debe y lo que no se debe hacer?. Este es el tema de esta presentación en vídeo en la que Mary Poppendieck da un repaso a los errores que, aunque son lugares comunes para la gestión de nuestros equipos, siguen siendo repetidos por demasiados "jefes": las reminiscencias majadearas de la aplicación científica del trabajo, los mitos de la motivación, la gestión sin referencias, las culturas orientadas a la tarea, la fe ciega en los procesos, ignorar el origen del comportamiento X o Z, etc.

Un buen sitio para dar los primeros pasos en PHP, CSS/HTML y Photoshop y HTML con tutoriales en vídeo para auto-didactas; en inglés, aunque se entienden bien sin necesidad de un gran nivel de "listening"

Algunos de los vídeos ya disponibles: Basics of PHP - Arrays in PHP - PHP Conditional Statements - PHP Pagination (part1) - PHP Pagination (Part2) - Cookies in PHP - Custom PHP Functions - Consuming RSS in PHP - CSS/HTML Perfect Page Headers - CSS/HTML Three Colum Layouts - CSS Rounded Corners - CSS Rollover Images...

• Directorio de SampsonVideos

Edward Yourdon afirma en su libro "Death March" que todos los proyectos que se llevan a cabo con la mitad de la agenda, del equipo o de los recursos necesarios, son marchas fúnebres.

Son funestos todos los proyectos que se llevan a cabo con la mitad de la agenda, del equipo o de los recursos que necesitarían, y los ingredientes que, combinados en mayor o menor proporción, están siempre presentes en estos proyectos son:

• Politiqueos e intereses innobles
• La ingenuidad y el optimismo de los jóvenes: "Esto lo hacemos en el fin de semana"
• La mentalidad empresa "startup"
• La mentalidad de soldado-héroe: "Los auténticos programadores no necesitan dormir"
• La intensificación de la competencia por la globalidad y la aparición de nuevas tecnologías
• La aparición inesperada de alguna crisis durante el proyecto

Funesto (RAE): Aciago, que es origen de pesares o de ruina - Triste y desgraciado.

Entre la lista de posts pendientes de leer, encuentro otro ("Are you really using Scrum") de ayuda para saber si avanzamos por el camino recto, o andamos descarriados y apartados de la doctrina; para lo que prescribe, como suele ser habitual en estos casos, algunos mandamientos: ¿Las iteraciones son de menos de 4 semanas?, ¿Probamos el software al final de cada iteración?...

Dejando a un lado cuál pueda ser el porcentaje de conocimiento, y cual el de majadería o de "post-copio - post-pego" con el que se ha elaborado la lista; hacer afirmaciones del tipo "esta es la verdad" no ayuda mucho a la evolución dialéctica del conocimiento, ni a la riqueza que supone el mestizaje desde el convencimiento de que ninguna verdad es absoluta, comenzando por la de uno mismo; y puede ser algo pretencioso, sobre todo en escenarios dialécticos rápidos de conocimientos adolescentes como el de la ingenieria de software.

Scrum, DSDM, Extreme Programming, CMMI, ISO 15504, Crystal, FDD, Prince2 PMI, ... son algunos de los modelos de procesos, métodologías o conjuntos de prácticas para mejorar el desarrollo de software y aportan un conocimiento muy importante, pero resultan mezquinos cuando afiman ser la doctrina verdadera, y empobrecen a los profesionales que se lo creen, anclándolos en sus convicciones, mientras el entorno sigue avanzando.

Fundamentalismo (RAE): Exigencia intransigente de sometimiento a una doctrina o práctica establecida.

• La presencia y permanencia de directivos incompetentes en posiciones de liderazgo dentro de la organización es el primer síntoma y causa de pérdida del talento
• El líder incompetente dificulta o bloquea la carrera profesional de su gente valiosa que, poco a poco, empezando por los mejores, va abandonando su departamento o la empresa
  
• Se suele hablar mucho de la gestión del talento, de cómo captarlo, retenerlo, motivarlo y desarrollarlo. Pero apenas se habla del 'no-talento'
• el talento entra a la empresa por un gran proyecto y sale de ella por un mal jefe
• Los números uno se rodean de números uno, y los doses, de treses y cuatros

Citas  del artículo "Circuitos de pérdida de talento " de José Medina, que descubro vía Seis. 

Del mismo autor: el prólogo al libro Gestión del Talento de Pilar Jericó. 

La semana pasada, en uno de los aparacamientos de la central de Google en California (Googleplex) me encontré con esta bicicleta en la que: un equipo de 7 ciclistas trabajan conjuntamente, la velocidad a la que avanzan depende del esfuerzo de todos; no tienen sentido los conceptos de "competición", "ganador"... o todo el equipo llega a la meta, o no llega nadie; hay un propietario del producto, miembro más del equipo, que es el responsable de decidir hacia dónde hay que ir, y por tanto responsable del product back-log del volante; el equipo está en continua comunicación directa; todos ven el trabajo de los demás...

Qué significativo encontrar una representación de espíritu ágil, no ya en las pizarras o en las prácticas de trabajo de Google, sino nada más aparcar el coche.

"Equipos auto-gestionados" es un valor de fondo del desarrollo ágil, más trascendental que la forma que adopta a través de prácticas de trabajo; y comprende dos conceptos: equipo y auto-gestión.

Nonaka y Takeuchi identificaron en los "campos de scrum" a un único equipo, no a un único grupo de trabajo. Detrás de esta diferencia hay valores culturales diferentes. En la cultura occidental los valores son el individualismo, la iniciativa individual, el esfuerzo individual y la recompensa individual.
En la cultura japonesa, al contrario, el individuo se subordina al esfuerzo colectivo. El trabajo en equipo y la dedicación desinteresada son la forma de alcanzar las metas colectivamente establecidas. Es mucho más que una cuestión de técnica de gestión.

Y para la que la auto-gestión sea real se necesitan dos factores: delegación y autonomía y no es fácil que se produzcan de forma real, porque transformar a las personas en equipos auto-gestionados no consiste en dar un toque de varita mágica o un espaldarazo cada persona y decirle: ya tienes autonomía. La autonomía uno no puede darla; es la persona la que tiene que tomarla.

1.- Proactividad
Identificar, analizar y prevenir los riesgos. Conocer a todos los interesados en el proyecto, y buscar a los que no se presentan.

2.- Desde el principio, tener el fin como objetivo
Estructurar las iteraciones del desarrollo de acuerdo a las metas del proyecto.

3.- Hacer primero lo más importante
Conocer las prioridades, y organizar el trabajo segúnsean.

4.- Buscar las opciones "win-win"
Satisfacer el mayor número de necesidades de negocio, con el menor esfuerzo.

5.- Entender al cliente antes de proponer la solución
Comprender los objetivos de negocio del cliente antes de empezar a diseñar la solución.

6.- Sinergia
El valor de un equipo bien coordinado e integrado es mayor que la suma del valor de sus miembros

7.- Aprender y mejorar en cada proyecto

 Extraido de:  "The seven habits of effective iterative development "