Estoy de acuerdo contigo.

Guillermo

Respecto al diseño, siempre se debe de realizar un diseño a alto nivel sobre qué es lo que se quiere conseguir, e incluso adentrarse un poco en detalles de desarrollo, como las librerías, marcos de trabajo (frameworks), lenguajes y demás elementos a tener en cuenta.

En proyectos “novedosos”, en los que se usan tecnologías no cotidianas para el equipo de desarrollo y se plantean “desafíos”, que podrían resolverse en poco o mucho tiempo, no se puede establecer una norma fija, pero si se puede preveer un tiempo específico para:

Problemática a resolver
Opciones a estudiar
Decisión de las opciones por las que decantarse
Desarrollo de las mejores opciones
Elección de la opción que evolucione mejor

Esto sí se ve en el diseño a gran escala, el número de posibles puntos “conflictivos” que se pueden llegar a encontrar, y el tiempo que se puede destinar a intentar resolver cada uno de ellos. En caso de que se complique, siempre se puede tomar una opción tangente y proponer una posible mejora para una futura iteración.

En lo que respecta al “colchón” estoy totalmente de acuerdo. Yo siempre agrego un mínimo del 10% a lo que se estima en un principio y no tengo en cuenta ni fines de semana, ni festivos, ni vacaciones de personal, por supuesto. Ahora que, en lo que respecta a faltas sin aviso, distracciones o ausencias por enfermedad… supongo que esto es como las “catástrofes naturales” que ningún seguro (o casi ninguno) cubre. A este respecto, en el que se incluyen cambios de prioridades, requisitos o ausencia de recursos humanos, no se puede hacer nada.

Me parece que el único “problema”, es el tiempo que se propone al desarrollo. En mi percepción en cuanto a trabajar con estas metodologías, es que se tiene que dar una estimación de tiempo una vez terminado el diseño del proyecto, ya que hasta entonces no puedes ver el nivel de dificultad que tienen los módulos a desarrollar, provocando así un desface de tiempo en partes que quizá pensabas que no serian mucho problema.

También nos encontramos con variantes que no se pueden controlar como son ausencias de enfermedad, vacaciones, distracciones, etc. Que provocan retrasos en el desarrollo.

Es bueno dar una o dos o semanas como “colchón”, dependiendo del tipo de proyecto, así también te da espacio para pruebas y optimización de algunos módulos o simplemente para no quedar “apretados” con la entrega del proyecto.

En cuanto a la metodología del gráfico y del Scrum, me parecen excelentes herramientas de planificación de desarrollo de software.

Saludos.