¿Es ágil en cuanto a desarrollo o gestión?

En un debate sobre de qué se trata Scrum, descubrí que tal vez no entendí totalmente lo ágil. Me parece que Scrum (que sin duda se considera un proceso ágil) tiene que ver con la gestión de características y sprints y roles y cosas que no tienen nada que ver con TDD, programación de pares, CI, refactorización y otras técnicas y prácticas centradas en el desarrollador que pensé ( hasta ahora) son el corazón de ágil. ¡Ahora estoy enfrentando una dificultad!

1) ¿Scrum es independiente de si los desarrolladores realizan prácticas ágiles?

2) ¿Se puede implementar Scrum en un equipo que no utiliza pruebas automatizadas? no realiza refactorización o no se adhiere a las prácticas de programación ágil?

Es un error común pensar que Scrum es igual a Ágil.

Ser ágil es seguir los cuatro principios del Manifiesto Ágil . Scrum es un proceso de gestión de proyectos consistente con esos principios, pero no es, en sí mismo, ser ágil. XP (TDD, programación de pares) es un proceso de desarrollo, también consistente con esos principios, y consistente con Scrum, pero no es ágil. Integración continua, entrega continua, DevOps, todo coherente con los principios ágiles.

Siga los principios, ante todo. Todas estas frases son solo metodologías que las personas han encontrado con éxito para ayudarlas a seguir los principios. Pero la parte principal de "ser ágil" es poder ajustar sus procesos a voluntad donde no siguen los principios de Ágil.

¿Scrum es independiente de si los desarrolladores realizan prácticas ágiles?

Scrum es un conjunto de pautas que alientan a un equipo a ser ágil.

¿Se puede implementar Scrum en un equipo que no utiliza pruebas automatizadas? no realiza refactorización o no se adhiere a las prácticas de programación ágil?

Muy difícil, porque al final de cada sprint debes tener un producto que funcione. Si tiene que hacer una prueba de regresión manual completa para demostrar que está funcionando, es probable que esto sea inalcanzable.

Alistair Cockburn (uno de los creadores del movimiento Agile) dice esto sobre Crystal Clear (una faceta de su metodología Agile):

Crystal Clear se puede describir a un oyente de Nivel 3 en las siguientes palabras:

“Ponga de 4 a 6 personas en una sala con estaciones de trabajo y pizarras blancas y acceso a los usuarios. Haga que entreguen software probado y en ejecución a los usuarios cada uno o dos meses, y de lo contrario déjenlos en paz ".

Esa es una definición de ágil, ciertamente para el personal de desarrollo experimentado que sabe lo que está haciendo y se puede confiar en que lo haga. Entonces, ¿eso significa que tiene que usar CI y TDD y programación de pares y todas las demás cosas de moda? En pocas palabras ... No.

Agile no se trata de seguir un conjunto de procesos, se trata de ser efectivo. Lo que eso significa para usted depende de su equipo y cómo funciona, qué es lo que le resulta útil. Si TDD no lo ayuda a producir código de trabajo, ¡deje de escuchar las luces menores que gritan sobre él en la web y no lo use! Si la Programación por parejas realmente ayuda a su equipo a concentrarse y hacer las cosas, entonces ignore a cualquiera que diga que es una pérdida de tiempo y organice a su equipo como una carrera de 3 patas en el día deportivo escolar.

Hace muchos años, agilicé, tantos que ni siquiera nos dimos cuenta de que estábamos agilizando: entregamos iteraciones del producto todos los meses y recorrimos los errores solucionados y agregamos nuevas funciones regularmente. Hicimos absolutamente cero pruebas unitarias ya que tales cosas no habían sido inventadas y el libro de refactorización no había sido escrito. Entonces, sí, puedes hacerlo ágilmente sin ninguna de las llamadas prácticas ágiles.

Alistair también dice esto de Kent Beck:

Cuando se le preguntó sobre XP y los cinco niveles del "Modelo de madurez de capacidad" del Instituto de Ingeniería de Software, respondió con los tres niveles de madurez de XP:

1. Haz todo como está escrito.

2. Después de haber hecho eso, experimente con variaciones en las reglas.

3. Eventualmente, no me importa si estás haciendo XP o no.

Eventualmente, no importa si estás haciendo XP o no ... palabras sabias que deberían recordarte que no caigas en esta trampa .

Scrum es un sabor ágil que sigue un patrón específico para cumplir con los objetivos de la metodología de desarrollo ágil. No puedes seguir a Scrum y no ser ágil, pero puedes ser ágil y no seguir a Scrum.

Scrum no tiene relación con el uso de pruebas automatizadas, ágil tiende a favorecerlas, pero de ninguna manera son necesarias. La refactorización debería ser un objetivo en ágil y Scrum, pero a menudo se ignora. no tener la intención de refactorizar nunca es realmente ágil.

¿Es ágil en cuanto a desarrollo o gestión?

Agile es un conjunto de prácticas de desarrollo de software para cumplir con la flexibilidad y los rápidos requisitos de cambio de fase del mercado, o lo que se conoce como entrega acelerada . En general, se trata de un enfoque flexible para cumplir con los requisitos complejos y cambiantes del cliente dividiendo el trabajo en pequeños espacios y brindando funcionalidad en iteraciones rápidas de 2 a 4 semanas.

Sin embargo, para cumplir con esta flexibilidad, el equipo de desarrollo necesita practicar prácticas de programación ágiles .

Descripción de Wiki con respecto al desarrollo de software ágil :

El desarrollo ágil de software es un grupo de métodos de desarrollo de software basados ​​en el desarrollo iterativo e incremental, donde los requisitos y las soluciones evolucionan a través de la colaboración entre equipos autoorganizados y multifuncionales. Promueve la planificación adaptativa, el desarrollo evolutivo y la entrega, un enfoque iterativo de tiempo determinado y alienta una respuesta rápida y flexible al cambio. Es un marco conceptual que promueve las interacciones previstas a lo largo del ciclo de desarrollo.

De hecho, puede usar scrum en proyectos que no tienen nada que ver con el desarrollo de software. Es un método de gestión de proyectos / gestión de equipos.

1) NO !!!! Scrum es ágil, lo que significa que las prácticas ágiles de desarrollo (TDD, programación de pares, CI, refactorización, etc.) son muy importantes para todos los aspectos de un proyecto Scrum. Va a ser mucho más difícil determinar la velocidad de ejecución de sus equipos, estimar el trabajo, establecer el tamaño de sprint apropiado, etc., si no está utilizando estas prácticas.

2) Sí, puedes implementar Scrum en un equipo que no se adhiere a las prácticas ágiles, pero creo que realmente limita el potencial del equipo. Una gran parte de por qué Scrum / Agile son tan exitosos es el rendimiento y las ganancias de calidad que obtienes de las prácticas de desarrollo de Agile, que son fundamentales para ofrecer funciones completas de adelante hacia atrás en cada sprint.

Si alguien más en su grupo está tratando de convencerlo de que las prácticas de desarrollo ágiles son una pérdida de tiempo, creo que debería dedicar algo de tiempo para enfatizar por qué estas prácticas siempre están estresadas tanto con Scrum como con Agile en general. Realmente hacen la diferencia.