agile - trabajo - Convertirse en ágil
scrumban ventajas y desventajas (7)
¿Alguien tiene alguna buena técnica o ejemplos sobre cómo promover los beneficios de las prácticas de desarrollo Agile en un entorno corporativo impulsado por una cascada?
Recientemente cambiamos al desarrollo basado en características, usando administración de código troncal y de rama, tenemos un proyecto funcionando bien con scrum, pero es difícil conseguir este enfoque adoptado por las masas más amplias.
Me preguntaba si alguien más está luchando contra la máquina corporativa.
Gday,
Es posible que desee escuchar la charla de Ken Schwaber sobre Scrum en Conversaciones de TI.
Si bien se centra en una "implementación" particular de Agile, cubre muchas de las razones básicas por las que Agile tiene éxito.
También puede consultar los artículos sobre la introducción de Agile en la Agile Alliance.
HTH.
aclamaciones,
Robar
Mejor ROI en general.
Un proceso en cascada se vuelve redundante para cuando hayas terminado debido a la cantidad de tiempo que lleva completarlo. Para cuando haya terminado, el cliente ha cambiado la forma en que trabaja.
Esta es la razón por la cual el desarrollo iterativo y las liberaciones iterativas funcionan mucho mejor que la cascada. Pasará menos tiempo desarrollando paquetes redundantes y también hará que el cliente sea más feliz al poder responder mejor a los cambios en sus requisitos.
El paradigma en general es mejor. No planificas y creas la perfección. Supone desde el principio que no será perfecto y "hace crecer" el software haciéndolo flexible y fácil de cambiar.
Si la organización no reconoce que tienen un problema (y muchos no quieren saberlo), entonces tiene una batalla cuesta arriba.
Puede sugerir que reduzca el alcance de los proyectos (y, por lo tanto, el tamaño del intervalo entre las entregas) sin cambiar la metodología.
Las fases de la cascada, que pueden incluir análisis, diseño, código, prueba, implementación y revisión, no son en sí mismas el problema. Asignarlos a un proyecto con alcance restringido a una sola característica: el análisis se convierte en comprensión de la historia del usuario, el diseño y el código se convierten en un bucle TDD, la prueba es la aceptación del usuario y luego la ponemos en producción. Acabamos de hacer una unidad de trabajo más pequeña en unos pocos días en lugar de todo el sistema en unos pocos años.
Podría funcionar.
Si ya tiene un proyecto de scrum funcionando bien en su organización, el 90% de la batalla está lista.
Sugeriría tomarse un tiempo para escribir un caso de estudio, tal vez ponerlo en su intranet o similar. Descubra quién lidera los otros proyectos que consideraría buenos candidatos y charle con ellos. No se salga de toda prédica - Solo ''oye, bueno, solía tener el problema que describes, si alguna vez quieres ver cómo estamos ejecutando proyectos ahora, eche un vistazo a http: // xyz /
La otra opción es lograr que alguien de alto rango en su organización lo defienda. Eso hará que la transición sea mucho más rápida, pero requiere que encuentres un campeón adecuado y los convenzas de los beneficios.
es un buen recurso para obtener información ágil, especialmente para gente de tecnología que se mueve hacia la administración.
Manning Publishing tiene un libro de Greg Smith y Ahmed Sidky sobre este tema: enlace de texto
Creo que la mejor manera es comenzar siendo pequeño y demostrar que el enfoque realmente funciona.
Como se discutió anteriormente, Scrum y otras técnicas ágiles se pueden introducir paso a paso .