¿Su equipo funciona bien sin seguir una metodología de trabajo (como scrum)?

He trabajado en varios equipos pequeños durante los últimos 9 años. Cada uno tenía las buenas prácticas obvias, como reuniones cortas, control de revisiones, software de integración continua, seguimiento de problemas, etc.

En estos 9 años, nunca he escuchado mucho acerca de las metodologías de desarrollo; por ejemplo, nunca ha habido un "estamos haciendo scrum", o "vamos a hacer ágil", o algo más que una referencia pasajera. Todos los equipos parecían funcionar bien, sin seguir mucho proceso, simplemente fluíamos libremente y, naturalmente, funcionábamos bien.

¿Alguien más ha progresado durante largos períodos de tiempo sin encontrar scrum / agile / etc?

La única exposición que he tenido a estos es a través de sitios como este. Leí preguntas como Sprint Meetings: de qué hablar ... y toda la charla parece describir casi robótica como las personas que siguen una metodología de máquina de estados finitos. ¿Es realmente (aunque exagerado) así? Me pregunto si las personas que publican en Internet solo son partidarios de la "mejor práctica", con visiones similares de libros de texto, que realmente no reflejan cómo trabajan las personas ... O que me he encontrado con algunos equipos que crean sus procesos de forma natural.

Además (estoy en el Reino Unido, lo que puede ser relevante) ... Creo que si se introdujera una metodología en cualquiera de los equipos en los que trabajaría, simplemente la rechazarían por ser tonta e innecesaria ... y luego llevar en. Tiendo a estar de acuerdo, seguir los procesos parece un poco antinatural. ¿Es esto típico o común?

Más de 20 años de experiencia en desarrollo aquí, y nunca he usado una metodología formal. Nunca los necesité, y no planeo usar uno en el futuro. Las metodologías pueden estar bien para algunas personas, pero no pueden sustituir a los programadores expertos que escriben código probado y bueno.

Personalmente, creo que a mucha gente le importaría menos seguir la nueva metodología más actual del día y centrarse más en la calidad del código.

Honestamente, si su pequeño equipo ha estado trabajando bien sin incidentes importantes durante todos estos años sin pensar en el proceso, probablemente esté haciendo algún tipo de agilidad. Todo lo que significa un proceso ágil es que cumple con el "Manifiesto Ágil" http://agilemanifesto.org/ que tiene poco que decir sobre iterativo, guiones gráficos, etc. El primer inquilino de ágil es que prefiere "Individuos y interacciones sobre procesos y herramientas ". Cualquier equipo que trabaje bien en conjunto no necesita pensar mucho sobre el proceso.

Las diferentes marcas de ágil (como Scrum, etc.) son muy útiles si tiene un nuevo equipo que no está acostumbrado a trabajar entre sí. En cierto modo, establecen el marco de trabajo para construir un equipo cohesionado, que a su vez creará un producto cohesionado.

Si lo que estás haciendo funciona, sigue haciéndolo. Si constantemente llega tarde con los entregables, tener que tirar rutinariamente horas extras o corregir errores importantes después de implementar algo, entonces algo está mal. Es entonces cuando realiza una serie de pequeños cambios para solucionar los problemas.

Si todo está bien y siempre está bien, entonces no hay problema, por lo que introducir una nueva metodología (sus equipos habrán seguido algún tipo de metodología, formal o de otro tipo) sería una pérdida de tiempo.

Sin embargo, cuando las metodologías realmente ayudan es cuando el equipo se encuentra con problemas o tiene problemas de fuentes externas: una metodología no solo introduce buenas prácticas, sino que lo ayuda a protegerlos . Es mucho más fácil mantener buenas prácticas bajo estrés cuando las estás haciendo conscientemente, de lo contrario, pueden exprimirse rápidamente.

No creo que necesite necesariamente una metodología formal, pero cada equipo necesita algún tipo de patrón (no necesariamente repetitivo, podría estar impulsado por eventos) para que su trabajo sea eficaz en mi humilde opinión.

Si no tienes ningún problema que resolver, por suerte.

He visto muchos equipos (especialmente en empresas muy pequeñas) que funcionan bien sin ninguna metodología definida.

Implementar una metodología (o técnica) porque es divertido o porque lees esa publicación de blog en Internet es muy peligroso.

Si estás bien, no cambies nada. Solo intenta algunas optimizaciones cuando puedas.

Hay una gran variedad de metodologías, algunas bastante sensatas, otras que bordean lo loco. Todos parecen codificar el sentido común , darles un nombre divertido y luego vender muchos libros / seminarios / etc.

Ahora bien, si su administración, o de hecho su equipo, carece de sentido común y no tiene orgánicamente sus propias metodologías sensibles (ya sea consciente o no), entonces puede valer la pena estudiarlas y luego tener en cuenta las partes de la metodología relevante para las experiencias de ese equipo .

La imposición general de las últimas <insert-buzzword-here>prácticas de trabajo puede causar más confusión de la que pretende resolver. Pero, por lo general, puede proporcionar muchas métricas de casillas de verificación que un administrador de línea sin codificación puede marcar con entusiasmo.

Tal vez no lo llamaste ágil o scrum, pero eso no significa que no tuviste ningún proceso y no lo estabas usando.

Al igual que el desarrollo de software en sí. Probablemente usará varios patrones de diseño aunque no piense explícitamente en ellos por sus nombres.