¿Cuál es el impacto de ITIL o CMMI en el desarrollo?

Question

He leído muchos libros sobre qué prácticas funcionan bien o no en el desarrollo de software. Y NUNCA he escuchado acerca de metodoly como ITIL o CMMI en cualquier webcast o libro o blogs en el campo de desarrollo.

He oído hablar de estas metodologías en mi escuela, y para mí parece ser una práctica burocrática.

Sin embargo, todos los libros sobre desarrollo que he leído hablan sobre colaboración, o personas sobre documentación. (Sí, muchos libros ágiles)

Así que mi pregunta es: ¿Las metodologías como ITIL o CMMI tienen algún impacto o relación con el desarrollo o la vida cotidiana del desarrollador? ¿Y tienes grandes libros o blogs que hablan sobre algunas buenas ideas en estas metodologías que puedo usar en un equipo de desarrollo?

Answer 1

ITIL está más centrado en la infraestructura y el soporte y no en el desarrollo, por lo que la discusión de ITIL es probablemente más apropiada en la versión de StackOverflow enfocada en "TI" que supuestamente está en desarrollo. Por otro lado, considero una excepción llamar a ese otro sitio "TI" centrado ya que TI abarca infraestructura, soporte y desarrollo en la mayoría de las empresas ... probablemente un buen porcentaje de usuarios de StackOverflow son desarrolladores en departamentos de TI.

He trabajado con CMMI y Team Software Process (TSP), ambos productos de Watts Humphrey y el Instituto de Ingeniería de Software Carnegie Mellon. Si está comprometido con la mejora continua y cree que la medición está en el corazón de cualquier mejora continua, entonces encontrará valor en CMMI.

Es muy fácil hacer CMMI (y TSP) mal o de una manera que aliena a los desarrolladores y finalmente termina como escaparate o algo que se ve bien en una pila de certificaciones. Mira a los proveedores de desarrollo en India ... son milagrosamente todos CMMI nivel 5.Lo que no le dicen es que casi siempre fue un pequeño proyecto o equipo en su organización que trabajó duro para obtener la certificación, pero las prácticas repetibles simplemente no están presentes para el 95% de su organización.

El enfoque en el seguimiento del tiempo (marcación del reloj), seguimiento de defectos (cuotas de errores), líneas de código (muchas formas de "jugar" si así lo desea) y hacer que su proceso sea repetible (haciendo que el desarrollador se sienta un engranaje sin libertad para innovar) apaga a muchos desarrolladores. < - tenga en cuenta los contraargumentos desgastados entre paréntesis.

El hecho es que el 90% de los desarrolladores (pocos de los cuales leen StackOverflow o cualquier blog técnico/sitio web) se disparan y carecen de conciencia de dónde residen sus oportunidades de mejora. Para ellos, el rigor del proceso y la oportunidad de realizar mejoras incrementales en la calidad a través del autoconocimiento de que la repetición y la medición facilitan son componentes valiosos de CMMI.

Bien hecho, obtiene los mismos beneficios de los métodos ágiles como Scrum, donde una vez más, el foco está en iteraciones repetibles, aprendiendo de cada iteración, y mejorando/estrechando en su objetivo. Se requiere mucha madurez y experiencia para liderar un equipo en la adopción de métodos Agile o CMMI y obtener el máximo valor de ellos.

Agile es sexy y CMMI está tan lejos de ser sexy como se puede obtener, razón por la cual no se habla mucho de eso.

Answer 2

La adopción ágil tiende a ser ascendente: los técnicos se topan con ella y la recomiendan a la gerencia.

ITIL/CMMI tiende a ser de arriba hacia abajo: la administración se tropieza con él y lo empuja hacia los expertos en tecnología.

Eso no hace que uno sea bueno y el otro malo; mayormente eso afecta el lenguaje utilizado para describir cada enfoque. Y hay muchas excepciones: personas con experiencia en las trincheras que son buenos para aplicar CMMI, y gerentes que experimentan agilidad.

Google para "CMMI ágil" y obtendrá muchos éxitos. Prefiero no recomendar uno en particular, porque es un debate en curso (es decir, algunas de estas personas simplemente están equivocadas).

En mi opinión, la noción de proceso es sin duda una idea útil al analizar el trabajo diario de desarrollo de software. La idea de que hay algunas actividades recurrentes, y que estas actividades a menudo están organizadas en secuencias similares, es un buen punto de entrada para hacer preguntas que conducen a la mejora. También puede obtener un poco de kilometraje preguntando qué es repetible y bajo qué condiciones se pueden llamar actividades administrado.

El error y los excesos comienzan cuando se establece el pensamiento mágico: "Si describimos (en papel) el Proceso Perfecto y lo documentamos con precisión, la gente lo seguirá y obtendremos el software perfecto". No funciona de esa manera.