significado metodologia fases ejemplo agile scrum

agile - metodologia - scrum significado



Es Scrum Evil? (15)

Como dijo F. Brooks, "no hay una solución mágica", y los procesos ágiles no se apartan de esto y no se pueden aplicar para todo tipo de proyectos.

Además, Scrum y los procesos ágiles son más que un conjunto de prácticas, existen principios subyacentes . Si aplicar las prácticas puede ser fácil, sin esos principios, puede conducir a un desastre. Y al inspeccionar y adaptar el proceso de forma continua , el proceso terminará adaptándose a las necesidades.

Es obvio que Scrum está sufriendo de proyectos [mis-] usando Scrum y fallando. Es inevitable. Pero vimos fallar los proyectos de Waterfall, vimos que fallaron los proyectos de RAD, vimos que fallaron los proyectos de RUP, ¿qué nos enseña sobre esos procesos?

Personalmente creo que los procesos ágiles han alcanzado su nivel de madurez, no estoy seguro de que esto signifique que comenzaron a declinar.

En la última reunión de CITCON Europa tuvimos una gran sesión sobre el tema " ¿Es Scrum Evil? " Leí la sesión de blog de James Shore sobre " La decadencia y la caída de Agile ".

Estas son serias dudas planteadas por personas profundamente profundas en ágil. Para las personas en el exterior, los juicios pueden ser aún más duros, como en este blog " The Agile Disease ".

¿Cuál es su visión actual de Scrum y / o Agile y su influencia actual en el desarrollo de software?

(Esto no se trata de lo que ágil significaba hace más de 5 años, se trata de su influencia en la actualidad. ¿No es tanto Scrum vs. RUP, pero más es Scrum el nuevo RUP?)

Algunas observaciones sobre aspectos negativos de SCRUM en mi experiencia:

Un sentido de detalle engañoso.

Hay tantos detalles de procesos específicos en SCRUM que es muy fácil quedar atrapado en el proceso mientras se pierde de vista los objetivos de alto nivel (y luego se convierte en solo un proceso de culto a la carga). Además, SCRUM genera una gran cantidad de artefactos, es fácil engañarse y creer que esta gran cantidad de datos le da más visibilidad del proceso de desarrollo de lo que realmente es, y la gran cantidad de datos probablemente desanime a las personas a preguntar si están recibiendo la información correcta.

Sobre la aplicación.

SCRUM a menudo se aplica erróneamente como un proceso de solución general para todas las situaciones cuando, como cualquier proceso, solo tiene utilidad dentro de un conjunto bastante estrecho de circunstancias.

Presión por miopía

SCRUM fomenta el trabajo a corto plazo en tareas definidas concretamente. El trabajo menos definido (especialmente el trabajo que no tiene artefactos ya existentes en el sistema), como la investigación o la planificación estratégica, está en desventaja para que el desarrollador tenga tiempo.

Crédito fuera de lugar

SCRUM es uno de los procesos de desarrollo más visibles, ayuda a que tenga un nombre / marca pegadiza, lo que significa que a menudo un proyecto exitoso que utiliza SCRUM tiene más probabilidades de dar como resultado que SCRUM reciba una buena cantidad del crédito que un proyecto exitoso que emplea un proceso de desarrollo que es menos perceptible y no tiene un nombre tan pegadizo.

FUD

Los más entrenados en SCRUM parecen ser los más ciegamente a la defensiva, llegando incluso a intentar asustar a la gente para que piense que incluso la más mínima desviación del camino verdadero-SCRUM conduce al temido proceso de "cascada". Dada la enorme multiplicidad de procesos de desarrollo diferentes, muchos de ellos con muchas buenas cualidades, esta tendencia es bastante ridícula. Además, existe la idea de que la única forma de ser ágil es usar SCRUM (TM) o TDD (TM) o XP (TM), cuando en realidad hay muchas maneras de lograr la agilidad de desarrollo sin ninguna de estas metodologías específicas. La verdad es que ningún proceso de desarrollo es una bala de cristal, y los mejores procesos de desarrollo son en realidad solo incrementalmente mejores que los mejores procesos de 2º, 3º, etc.

Creo que puede ser útil en ciertas circunstancias. Pero creo que SCRUM, o cualquier otra metodología, debe ser un instrumento para nosotros, y no a la inversa.

Cuando comienza a crear más problemas de los que soluciona, no vale la pena el tiempo.

Si después de usarlo, estás mejorando tus estimaciones de tiempo, tu equipo es más consciente de sus objetivos, detecta retrasos antes y puede reaccionar ante ellos, entonces el scrum te está sirviendo.

Pero cuando descubres que tienes que pasar mucho tiempo simplemente tratando de hacer las tareas de asignación de rompecabezas a los desarrolladores y adaptándolas a tu tiempo de iteración, cuando tienes que hacer una estimación de tiempo sobre una tarea que no está bien definida, cuando tiene que hacer cuánto costará implementar una tecnología que ni siquiera conoce, etc ... solo para que la administración pueda tener un gráfico de iteración bastante bueno, entonces es una completa pérdida de tiempo (y, por supuesto, dinero). De hecho, es una fuente de frustración, hace que el desarrollo sea más difícil y la administración casi imposible porque no puede generar buenos datos, sin importar cuánto lo intentes.

Curiosamente, el enlace scrum evil no da un punto de vista particularmente negativo en mi opinión:

por ejemplo, "Scrum es malo porque ..." cuando falla, todas las personas involucradas piensan que todo lo ágil no es bueno (envenena el pozo por ágil)

El punto en ese artículo parece ser que centrarse en "el proceso" más que en el objetivo es el problema. Esto se aplica a cualquier metodología.

Del mismo modo, la publicación Decline and Fall está diciendo que aplicar ciegamente un proceso (en particular SCRUM con su enfoque de gestión) sin respaldarlo con buenas prácticas de ingeniería no tiene sentido.

Creo que el punto es que no puedes tomar ningún proceso al pie de la letra e intentar copiarlo a ciegas (o peor solo las partes que quieres) y esperar que funcione. Cada situación es diferente y sin un pensamiento claro, buenas prácticas y personas talentosas y motivadas con las que va a luchar.

Curiosamente, hace poco escuché un discurso de conferencia de Tim Bray cuyo tema era "cómo sobrevivir a la crisis crediticia" (más o menos) y su punto de vista era que ágil no solo está lejos de estar muerto, sino que será el único jugador por un tiempo y es una cascada que está muerta.

Su razonamiento sobre esto parece perfectamente claro y obvio para mí que donde el dinero es ajustado ningún negocio o cliente se comprometerá con enormes costos iniciales donde la falla es casi terminal para un proyecto cuando tienen la opción de pequeños costos iterativos donde la falla simplemente manda otra iteración. Puede discutir todo el día sobre el riesgo relativo, pero sé por experiencia que solo ágil le brinda al cliente una sensación de seguridad y control.

Ciertamente, el alcance de "ágil" lo convierte en un arma cargada en las manos de un equipo de mala gestión, y tengo menos tiempo para cosas como XP y sesiones de scrum de una hora, pero eso no es un defecto del principio de desarrollo ágil. Ciertamente, la publicación de SGS señala que las metodologías más rígidas pueden adaptarse mejor a desarrolladores mediocres y software de línea de fábrica, pero estoy seguro de que eso no se aplica al OP;)

En la pequeña amplitud de mi carrera hasta ahora, puedo decir que cada proyecto de una cascada se ha convertido en un desastre cuando el foo golpea la barra, y solo los ágiles (completamente abrazados) han contado con el apoyo de todas las partes en el final del proyecto ¿Es un prejuicio favorecer lo que siempre ha sido mejor?

Resumen: estoy totalmente en desacuerdo. Agile es el futuro.

No creo que el scrum sea "malo", pero sí creo que cualquier implementación pura de una metodología tendrá sus fallas. El objetivo es tomar una o más metodologías que sean atractivas para un equipo y aplicar esas características a su proceso. En mi experiencia, cualquier enfoque puro se vuelve demasiado rígido y no satisfará las necesidades de todos los interesados ​​en un proyecto.

No creo que sea malo, pero creo que puede ser mal aplicado. Dos ejemplos vienen a la mente. Si está trabajando en un producto maduro que ha funcionado sin problemas utilizando la cascada durante los últimos 10 años, no creo que valga la pena reciclar a todos los desarrolladores en un nuevo proceso. También creo que Scrum fracasará si el equipo o entrenamiento adecuado no está en su lugar. Si tienes muchos desarrolladores experimentados en un equipo, Scrum funcionará si la gerencia compra en él. Intentar ejecutar un nuevo proyecto con pasantes y la metodología de Scrum no funcionó muy bien, aunque no había mucha capacitación y los pasantes no tenían la experiencia suficiente para mantenerse en la tarea sin supervisión constante.

Scrum NO es un reemplazo para la gestión de ingeniería de software real. Alguien todavía tiene que asegurarse de que el código es bueno, el proyecto está progresando de acuerdo a las necesidades del negocio y la experiencia del usuario está saliendo bien. Scrum hace que todas las cosas sin importancia parezcan más importantes. Se trata de mirar a los árboles y perder totalmente el bosque.

La otra cosa que odio del scrum es que los scrums tienden a ser reuniones extremadamente dolorosas en las que no se discuten cosas interesantes, y el equipo se enoja tanto que las cosas interesantes dejan de discutirse en cualquier parte. Asegura que la innovación y la diversión sean eliminadas del proceso de desarrollo. Lleva a software de baja calidad y aburrido.

Viví con "Agile" y "Scrum" durante un año, y he visto a muchas otras compañías usarlo. Estoy convencido de que "hacemos ágil" simplemente significa "no tenemos ningún instinto o sabiduría sobre el desarrollo de software, por lo que nos escuchamos hablar durante 30 minutos al día y pretender que somos buenos en esto".

Ok, sí, en mi experiencia, el scrum es malo. "Agile" es una gran palabra de marketing, pero una metodología terrible.

Scrum es una reacción a la Cascada degenerada. En su forma original, Waterfall tenía comentarios sobre el paso anterior en cada nivel. Cuando eso falta, es muy fácil fallar mal. Esto ha sido ampliamente demostrado por la enorme fracción de proyectos de TI gigantes que fallan completamente sin ningún beneficio para aquellos que pagan las tarifas.

En mi opinión, Scrum introduce dos diferencias realmente valiosas de Waterfall no generado, probando ideas y resultados parciales con grupos de interés como clientes y usuarios finales, posiblemente mediante el uso de sustitutos, y ciclos muy cortos que aprovechan ver hacia dónde te diriges enfrentando la realidad temprano y a menudo. Es decir, colabora con tus clientes y observa lo que estás haciendo y qué tan bien está funcionando.

Aún así, si desea los caminos más efectivos para la gloria, realmente necesita comenzar con los objetivos de calidad más altos de la organización en forma medible y usar esa comprensión para elegir el siguiente paso (sprint si lo desea) estimando su efecto en el progreso hacia esos objetivos . Tom Gilb (ver Gilb.com) proporciona métodos detallados en su manual de "Ingeniería Competitiva", aunque sus "Principios de la Administración de Ingeniería de Software" mucho más antiguos son mucho más fáciles de leer de principio a fin.

Su advertencia para seleccionar y adaptarse de entre la avalancha de grandes ideas que ofrece es una gran fortaleza de su enfoque.

Scrum no es malo, pero las personas pueden serlo. Si un equipo no entiende los principios [ 1 ] más allá de las prácticas, fallarán y, por supuesto, culparán a Scrum o a cualquier otra metodología ágil que crean que están usando.

Las personas pueden querer usar Scrum, pueden leer mucho y pueden entender cómo usarlo, pero el problema es que la mayoría de las personas no entienden por qué lo están usando. Simplemente piensan que usar Scrum hará que se vean mejor y que los clientes les encantarán.

El camino a Agile está lleno de dolor y trabajo duro. No es nada fácil. Es un cambio cultural, una nueva mentalidad si lo prefieres [ 2 ].

Es por eso que creo que antes de aprender Scrum, programación extrema o cualquier otra Metodología Ágil las personas deberían leer sobre Lean Thinking [ 3 ]. Los principios que debemos entender están disponibles allí.

Referencias

[ 1 ] - http://www.agilemanifesto.org/principles.html

[ 2 ] - http://www.mrbool.com/articles/viewcomp.asp?comp=7480

[ 3 ] - http://www.lean.org/

Primero, acepte SCRUM por lo que es, un conjunto de prácticas de administración para facilitar la colaboración entre el desarrollo y el socio comercial. Como conjunto de prácticas de gestión, por lo general son fáciles de implementar y seguir, y proporcionan un beneficio casi inmediato para un proyecto.

SCRUM no es un conjunto de prácticas de ingeniería. Un equipo sin un conjunto de prácticas de ingeniería es un equipo que no podrá mantener la entrega. SCRUM por sí solo no es suficiente. Un equipo ágil que solo practique SCRUM comenzará a perder su velocidad. Sin las prácticas de ingeniería adecuadas, por ejemplo, XP, la base de códigos se vuelve más difícil de cambiar cuanto más se ejecuta el proyecto.

Por lo tanto, SCRUM por sí solo proporcionará un beneficio a corto plazo y puede crear un falso sentido de valor. SCRUM sin prácticas de ingeniería como XP, pronto se convertirá en un proyecto que necesita ser rescatado. SCRUM es un excelente conjunto de prácticas de gestión que necesitan un excelente conjunto de prácticas de ingeniería que deben practicarse en paralelo.

No sé mucho sobre Scrum, y definitivamente no es suficiente para decir si es "malo" (también creo que "mal" es un término usado en exceso y engañoso de todos modos, pero esa es probablemente otra discusión). Pero como con casi cualquier cosa, creo que el fanatismo y el fundamentalismo son malos incluso cuando la intención es buena.

Conozco un poco sobre XP y otras metodologías "ágiles", y hay muchas buenas ideas en muchos de estos, pero siempre lo he considerado como sugerencias, no como una fórmula para seguir de manera metódica. Mi principal preocupación con respecto a todos los modelos de desarrollo es que requieren desarrolladores capacitados, inteligentes y automotivados para funcionar perfectamente, y dado que muchas de las mejores ideas son realmente de sentido común para las personas inteligentes, parece un poco exagerado. Incluso puede obtener el estilo de vaquero, "codificar y corregir" para funcionar si todos los desarrolladores son buenos y disciplinados. Pero cualquier metodología fallará con un equipo mayoritariamente incompetente, y seguir ciegamente algún "manifiesto" sin sentido común no lo hará mejor.

Lo opuesto a "ágil"; sistemas burocráticos pesados; en realidad puede funcionar mejor para desarrolladores mediocres, que un sistema que requiera participantes autodirigidos; aunque puede alejar a muchos desarrolladores creativos e inteligentes. El principal problema es encontrar buenas personas, no tanto cómo ejecutar el proyecto ...

Por cierto: personalmente me gustan las ideas ágiles, y uso las que más me convengan, pero también veo que no funcionaría si mis compañeros de trabajo y yo no somos buenos en la gestión de nosotros mismos.

Personalmente ... creo que Scrum es más fácil de aceptar por el estilo de gestión de viejo estilo científico que cualquiera de los métodos ágiles que existen. Scrums que deberían tomar 30 minutos o menos de morph en las actualizaciones de estado de larga ejecución de antaño ... (¡ahora a diario y de pie!)

Como con la mayoría de las cosas ágiles ... creo que la falla radica en

  • sin entender los principios detrás de la metodología ... lo que lleva a seguir las prácticas enumeradas sobre la fe ciega ... y la impotencia cuando no funcionan
  • no adaptar la metodología al problema en cuestión. Estandarizar es tan tentador ... persiguiendo soluciones templatizadas para todos los problemas. ''este es nuestro nuevo proceso. Todos deben cumplir ".
  • no se ajusta a las realidades de la tierra y retrospectivas.
  • Reparar los síntomas en lugar de la enfermedad.

La gente buena hará un buen software (incluso sin ágil, SCRUM, o lo que sea) ... las personas mediocres y bajas producirán un software similar incluso con su variedad local de ágil. Sin embargo, las personas que hacen un trabajo ágil, como se suponía, darán como resultado mejores productos

Actualización : JFYI. Acabo de encontrar un catálogo de " olores de Scrum " en el sitio de Mike Cohn . Corto, muy bien escrito y del hombre mismo.

Deberás dividir Software y Religión - Código Completo .

Elija y mezcle prácticas basadas en lo que se adapte a su proyecto actual. No hagas una metodología en una religión. Recuerde que todos somos de mundos diferentes . Steve McConnell ha estado aconsejándolo durante años: su libro Rapid Development ofrece un catálogo de prácticas con orientación sobre si se adaptan a su proyecto. El libro ganó un Premio Jolt en 1997, y Steve McConnell es muy respetado , por lo que es hora de darse cuenta.

Eric Sink lo expresó así (en tono irónico):

Admitiré que el cuerpo de la literatura de sabiduría producida por el movimiento Agile tiene algunas cosas muy buenas. Pero Agile no es diferente de cualquier otra religión importante como el cristianismo o el budismo. Aquí puede aprender algunos principios y prácticas excelentes, pero convertirse formalmente en un miembro es una decisión que no debe tomarse a la ligera.

Para ser justos, el desarrollo de software ágil de Alistair Cockburn también aconseja la selección pragmática de prácticas, pero en mi humilde opinión, algunos de los otros gurús ágiles son demasiado evangélicos. Otros lo expresan con más fuerza .