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

Question

Leí muchos libros sobre qué prácticas funcionan bien o no en el desarrollo de software. Y NUNCA he oído hablar de metodologías como ITIL o CMMI en ningún webcast, libro o blog en el campo del desarrollo.

He escuchado acerca de estas metodologías en mi escuela, y para mí parece que son prácticas burocráticas.

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

Entonces mi pregunta es: ¿Metodologías como ITIL o CMMI tienen algún impacto o relación con el desarrollo o la vida cotidiana del desarrollador? ¿Y tiene excelentes 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 enfocado en el lado de la infraestructura y el soporte y no en el desarrollo, por lo que la discusión sobre ITIL es probablemente más apropiada en el " IT " versión enfocada de StackOverflow que supuestamente está en desarrollo. Como comentario aparte, hago una excepción al llamar a ese otro sitio & Quot; IT & Quot; enfocado ya que TI abarca infraestructura, soporte y desarrollo en la mayoría de las empresas ... probablemente un buen porcentaje de los usuarios de StackOverflow son desarrolladores en los departamentos de TI.

He trabajado con CMMI y el Team Software Process (TSP), ambos productos de Watts Humphrey y el Carnegie Mellon Software Engineering Institute. Si está comprometido con la mejora continua y cree que la medición es la base de cualquier mejora continua, encontrará valor en CMMI.

Es muy fácil hacer un CMMI (y un TSP) incorrecto o de una manera que aleja a los desarrolladores y finalmente termina como un escaparate o algo que se ve bien en una pila de certificaciones. Mire a los proveedores de desarrollo en India ... milagrosamente son 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 allí para el 95% de su organización.

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

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

Bien hecho, obtienes los mismos beneficios de los métodos ágiles como Scrum, donde nuevamente el foco está en iteraciones repetibles, aprender de cada iteración y mejorar / reducir tu objetivo. Se necesita 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á lo más lejos posible de ser sexy, por lo que no escuchas tanto sobre eso.

Answer 2

La adopción ágil tiende a ser de abajo hacia arriba: 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 topa con él y lo empuja hacia los técnicos.

Eso no hace que uno sea bueno y el otro malo; principalmente que afecta el lenguaje utilizado para describir cada enfoque. Y hay muchas excepciones: personas con experiencia en las trincheras que son buenas para aplicar CMMI y gerentes que son muy ágiles.

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

En mi opinión, la noción de proceso es ciertamente una idea útil para analizar el trabajo de desarrollo de software diario. La idea de que hay algunas actividades recurrentes, y que estas actividades a menudo se organizan en secuencias similares, es un buen punto de entrada para hacer preguntas que conduzcan a una mejora. También puede obtener algo de kilometraje preguntando qué es repetible y bajo qué condiciones las actividades se pueden llamar gestionadas .

El error y los excesos comienzan cuando aparece el pensamiento mágico: " Si solo 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.