Desarrollo de Software. CMMI (Capability Maturity Model Integration). Nivel 2: Gestionado. Área de Proceso: Planificación del proyecto

La planificación del proyecto supone la base para la realización del mismo, por lo que es habitual que la mayor parte de las tareas que lo componen se realicen de una manera más o menos formal: Determinar un alcance inicial (aunque sea a alto nivel), hacer un análisis de riesgos, hacer una estimación del coste/esfuerzo, de los recursos en materia de personal (¿quiénes van a participar?, ¿cuándo?, ¿con qué dedicación?, ¿necesitan algún tipo de formación antes de enfrentarse al proyecto?) y materiales (software y hardware), definir el ciclo de vida/metodología a utilizar, proponer un cronograma, definir los hitos, las personas que los apruebas, etc…

Buena parte de la suerte del proyecto se juega al principio, una mala negociación, una mala estimación, en general, una mala planificación puede condicionar negativamente el proyecto, hasta tal punto de que si no hay posibilidad de enmendar la situación a tiempo puede afectar incluso a su viabilidad.

La incorporación de esta tarea y darle un grado de formalidad en los proyectos software, resulta por tanto, lógica en el nivel 2 de CMMI.

Es decir, a partir de ahora y en cada proyecto, es necesario que esas tareas preparatorias del proyecto se realicen, siguiendo un proceso, una estrategia, un plan. Se entiende que de esta manera las decisiones que se tomen se harán siguiendo una lógica que vendrá definida por las distintas soluciones y técnicas que se utilicen para realizar las diferentes actividades del mismo (estimación de proyecto, análisis de riesgos, etc…), si bien, la existencia de un proceso de guíe a la definición del plan de proyecto no asegura nada si la ejecución no es buena (ya sea por un incorrecto desempeño del que la realiza y/o porque la información que tiene para realizar la planificación no es adecuada o válida).

Se entiende que este área de proceso debería tomar como partida los requisitos del área de proceso “Gestión de requisitos”, sin embargo esto no va a ser siempre posible. Es cierto que es deseable conocer el mayor detalle posible antes de realizar por ejemplo una estimación de costes, pero también lo es que no siempre se van dar las condiciones para poder realizar esta tarea ya que la contratación del servicio de desarrollo de software se puede realizar en base a un pliego de condiciones técnicas o incluir dentro del mismo las tareas de análisis.

A lo anterior hay que sumar la volatilidad de los requisitos, ya que lo mismo la estimación se ha realizado teniendo en cuenta unos, pero después cambian las condiciones y se rompen los esquemas.

Dependerá de la organización tomar parte o no en un proyecto en función del grado de incertidumbre existente, de las características del cliente y de la propia cultura y experiencia de la misma.

Desde mi punto de vista la planificación inicial del proyecto es muy importante, independientemente del grado de incertidumbre y es importante que todas las partes entiendan que se trata de un plan inicial que se deberá ir ajustando a la evolución real del proyecto.

7 comentarios
  1. Ricardo dijo:

    Esto debería ser lo mínimo y por ley. Empresa que no lo cumpliera, prohibirle desarrollar software, porque seguramente desarrolle basura. Y aún quedan 3 niveles de mejora.

    Por cierto, CMMI choca con aquello del manifiesto ágil tanto en la planificación (improvisar) como en los procesos (primero las personas), ¿cómo explicas eso?

    • jummp dijo:

      Las metodologías ágiles no improvisan, no puedo estar de acuerdo contigo en eso. Es más, si se improvisase no sería posible ser ágil.

      Por otro lado que se le de más importancia al producto o a las personas no elimina la importancia de los procesos. Lo que viene a dar importancia las metodologías ágiles es al enfoque en lo más relevante pero sin olvidar que para conseguirlo se necesita una base, una estrategia, una forma de trabajar, una metodología.

      Totalmente de acuerdo en que realizar una planificación en los proyectos es esencial, de lo contrario es intentar escalar por un barranco, lloviendo y con los ojos tapados.

  2. Johann dijo:

    CMMi no olvidemos que es un nivel de madurez en base a comparación. No implica mucho más.
    Por este motivo, creo que CMMi no choca con nada, sino que simplemente indica el nivel de madurez de una organización.
    Una organización puede ser CMMi nivel 3 (lo más estandar) tanto con metodologías ágiles como sin ellas. Más que nada pq las metodologías ágiles no implican improvisar.
    En absoluto, la metodologías ágiles implican una falta de planificación, sino todo lo contrario. Desde mi punto de vista, las metodologías se denominan ágiles pq:
    1. Se centran en el producto (adaptación ágil a cambios)
    2. Se centran en las personas (documentación sí, pero nada de pasarnos con ella).

    Al centrarse en el producto, se centran en la planificación (timeboxes, sprints…), que es fundamental para entregar a tiempo.

    un saludo

Responder a jummp Cancelar respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: