"El producto previsto, en el tiempo planificado y por el presupuesto estimado" Vs. "Valor rápido, y de forma continua, en intervalos breves u regulares".

Implantar agilidad con un único equipo de 5-7 personas que trabaja en la programación de un único sistema, es un "caso de libro". No hay mas que tomar el libro de Ken Schwaber y aplicarlo. Pero esto  no es lo habitual en las empresas donde la mayoría de nosotros nos movemos, por eso, el que más y el que menos, nos las ingeniamos para aplicar las pautas ágiles en la forma que mejor sabemos y nos permiten las circunstancias.

Tener los requisitos cerrados antes de empezar a programar, y trazar con ellos un plan completo ¿es bueno o malo?

La respuesta es distinta si le preguntas a PMI o si le preguntas a la agilidad. Para PMI cada modificación de requisitos es una amenaza para el plan del proyecto, una incidencia que hay que medir y gestionar sus consecuencias.

Para la agilidad cada modificación de requisitos es una nueva aportación que va a hacer más valioso el resultado para el cliente.

Si nos planteamos si será mejor PMI o Scrum ya nos hemos limitado las opciones.

Añado Simple-Kanban al directorio de herramientas libres para gestión ágil. No tiene grandes funcionalidades, pero no se le puede pedir más: se trata de una simple página html: sin php, sin base de datos... nada que instalar, y para según que casos puede ser suficiente.

• Página de Simple-Kanban
• Demo

Aunque aún no está terminada la plataforma de e-learning de Scrum Manager; mientras toma forma, con la ayuda de Claudia y Marta, incluyo ya en la lista de herramientas de Navegápolis, esta hoja excel para llevar la pila del producto (product backlog), que incluye una macro con la que generar tarjetas para cada elemento en formato A5.

Es un trabajo para Scrum Manager Open Knowledge, derivado de los anteriores de Stefan Nijenhuis y la posterior modificación de Henrik Kniberg .

•  Pila del producto y tarjetas.
  

Nota: Las historias que hay a modo de ejemplo forman parte del ejercicio del próximo taller sobre product backlog en Scrum Manager OK.

Un actor capaz de conseguir el atractivo de Richard Gere, la constitución de Sylvester Stallone y el carácter de Jack Nicholson ¿sería una super-estrella?

Una ciudad con una torre metálica monumental, pirámides y calles "fluviales" con góndolas ¿Tendría más éxito turístico que París, El Cairo o Venecia?.

Es lo que se me ocurre con la idea de juntar "best practices". No sé si la comparación es válida, pero dudo de su resultado. Me convence más "romperlas" para descubrir su razón y fondo de conocimiento, y construir con la síntesis un modelo con personalidad propia, adecuada a mis circunstancias.

0. Ninguno

No se usa ninguna técnica de administración de proyectos y la organización no considera el impacto que supone para el negocio la mala gestión de proyectos.

1.- Inicial

Las técnicas de administración de proyectos dependen sólo de las decisiones particulares de cada gestor de proyecto. La dirección de la empresa no tiene ningún compromiso sobre la propiedad y administración de los proyectos. Ni el cliente ni los usuarios intervienen en las decisiones críticas de la gestión de los proyectos. La empresa no tiene una organización clara para la administración de los proyectos; no hay una definición de roles y responsabilidades, no hay una gestión seria de agendas e hitos, ni seguimiento de fechas y gastos.

El marco de trabajo ágil óptimo es un equipo único de no más de 6 ó 7 personas. La pérdida de eficiencia por el crecimiento de la estructura afecta también a un modelo ágil, y toma mayor dimensión si los equipos están físicamente separados.
Teniendo esto en cuenta, si el proyecto lo requiere, es posible emplear equipos de sincronización para coordinar en el mismo a varios equipos.

Se debe poner como primer elemento en la pila del producto (backlog), la construcción de la línea base de la arquitectura. Lo que Andy Hunt en "The Pragmatic Programmer " denomina como "bala trazadora".

Si monitorizamos el avance del trabajo sobre un plan previo, podemos tener como resultado: que estamos en fechas, o que vamos retrasados, pero nunca adelantados. Y aunque es una herramienta útil para cumplir fechas, también es un freno para reducirlas; de hecho, al seguir el avance de un sprint con un gráfico burn-down, siempre sale o sub-estimado, o bien; pero nunca sobre-estimado.

La gestión predictiva hace planes detallados de duración considerable, y registra el trabajo realizado en cada momento.

La gestión ágil lo hace de forma diferente: trabaja con planes detallados cortos (iteraciones o sprints) y registra, no lo que se ha trabajado, sino lo que falta para terminar. Son los gráficos de avance: burndown.

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.