¿Con qué métodos de desarrollo de software ágiles ha tenido más éxito?[cerrado]

Question

Hay numerosos Desarrollo Ágil de Software métodos.¿Cuáles ha utilizado en la práctica para realizar un proyecto exitoso y cómo contribuyó el método a ese éxito?

Answer 1

He estado involucrado con bastantes organizaciones que afirmaban trabajar de manera "ágil", y su procesamiento generalmente parecía basarse en XP (programación extrema), pero ninguna de ellas siguió todas las prácticas.

Dicho esto, probablemente pueda comentar algunas de las prácticas de XP.

• Examen de la unidad Parece resultar muy útil si se hace desde el inicio de un proyecto, pero parece muy difícil ingresar a una base de código existente y comenzar a intentar agregar pruebas unitarias.Si tiene la oportunidad de empezar desde cero, el desarrollo basado en pruebas es de gran ayuda.

• Integración continua Parece ser algo realmente bueno (o más bien, la falta de él es realmente mala).Dicho esto, las organizaciones que he visto suelen ser tan pequeñas que cualquier otro enfoque parece una tontería.

• Tarjetas de historias de usuario son buenos porque es genial tener un objeto físico para priorizar, pero no son lo suficientemente detallados a menos que su desarrollador realmente conozca el dominio o tenga un cliente en el sitio (lo cual nunca he visto). .

• Reuniones de pie Suelen ser realmente útiles para que los nuevos miembros del equipo conozcan a todos y en qué trabajan.Los veteranos rápidamente se relajan y simplemente dicen cosas como "Todavía estoy trabajando en X", lo cual han estado haciendo durante la semana pasada. Se necesita un líder fuerte para obligarlos a profundizar en los detalles.

• Refactorización Ahora es un término muy mal utilizado, pero cuando tienes suficientes pruebas unitarias, es realmente útil separar conceptualmente la actividad de "cambiar el diseño del código existente sin cambiar la funcionalidad" de "agregar nueva funcionalidad".

Answer 2

Scrum porque muestra dónde están los vagos.También identifica mucho más rápido que la unidad de negocio generalmente no tiene idea de lo que realmente quiere que se entregue.

Answer 3

Melé.

La reunión diaria es una excelente manera de asegurarse de que todo siga el rumbo y se esté avanzando.También creo que es clave involucrar a la gente del producto/mercado en el proceso de una manera real y significativa.Creará un entorno más colaborativo y eliminará gran parte de la basura conflictiva que surge cuando el equipo de producto y los equipos de desarrollo son "silos" separados.

Answer 4

Tener retrospectivas periódicas es una excelente manera de ayudar a un equipo a ser más eficaz y ágil.Más que adherirse a un estilo específico de Agile, esta práctica puede ayudar a un equipo a identificar qué está funcionando bien y adaptarse a un entorno cambiante.

Sólo asegúrese de que la persona que dirige la retrospectiva sepa lo que está haciendo, de lo contrario puede degenerar en una sesión de quejas.

Hay una serie de ejercicios que puede realizar un equipo para ayudarlos a reflexionar y extraer valor de la retrospectiva.Sugiero escuchar la entrevista con Linda Rising en Software Engineering Radio para una buena introducción.

Haga una búsqueda en Google de "Retrospectivas de latidos del corazón" para obtener más información.

Answer 5

He estado trabajando con un equipo utilizando prácticas de XP y Scrum salpicadas con algo de lean.Ha sido muy productivo.

Stand-up diario- nos ayuda a realizar un seguimiento completo de en qué y dónde están trabajando todos.

Programación en pareja- ha mejorado nuestra base de código y ha ayudado a eliminar errores "tontos" que se introducen en el sistema.

desarrollo iterativo- El uso de iteraciones de 1 semana nos ha ayudado a mejorar nuestra velocidad al establecer objetivos más directos, lo que también nos ha ayudado a dimensionar los requisitos.

TDD- me ha ayudado a cambiar mi forma de programar, ahora no escribo ningún código que no arregle una prueba rota y no escribo ninguna prueba que no tenga un requisito claramente definido.También hemos estado utilizando requisitos ejecutables, lo que realmente ha ayudado a los desarrolladores y BA a comprender los requisitos.

tableros kanban- mostrar en tiempo real dónde estamos.Tenemos uno para Milestone y para la iteración actual.De un vistazo se puede ver lo que queda por hacer y lo que se está haciendo y lo que se ha hecho y aceptado.Si no informa en su reunión diaria algo relacionado con lo que está en la pizarra, debe dar explicaciones.

equipo ubicado en el mismo lugar- todos están al tanto y en sintonía con lo que todos los demás están haciendo.La comunicación es justo a tiempo, muy productiva, no extraño mi cubo en absoluto.