agile - programming - scrum vs kanban vs xp

Mitos y conceptos erróneos ágiles (18)

"Estamos haciendo Scrum, así que no necesitamos (par | refactor | hacer TDD | ...)" En realidad, los fundadores de Scrum - Ken y Jeff han estado diciendo que todos los equipos de scrum de alta productividad implementan todo el rango de las prácticas de Programación Extrema.
El desarrollo basado en pruebas no encontrará todos los errores / no es fácil de aplicar a todo, ¡así que no vamos a intentarlo! - Aprender TDD no es un "acuerdo de todo o nada" y se mejora al juzgar qué probar y cómo hacerlo de manera eficiente. Lo he estado haciendo durante diez años y aún estoy encontrando mejores formas de hacerlo y nuevas cosas para considerar.
Puedo aprender todo lo que necesito para aplicar métodos ágiles de un libro. - Tienes que aprender haciendo y eso a menudo significa entrenar y conocer a otras personas que pueden ayudar. Muchas cosas salen mal cuando la gente simplemente intenta aprender de un libro.
Hysterical (y bastante real) "El candidato debe tomar la dirección de, y apoyar al scrum master" (Desde una especificación de trabajo que me enviaron la semana pasada ...) - Se supone que el maestro del scrum no debe decirle a la gente qué hacer . Él / Ella está allí para facilitar, es decir, para ayudar al equipo a aprender a resolver las cosas por sí mismos. Es un modo de falla masiva: ¡tener un maestro de scrum que "ordena" a la gente!
Hablando de "la metodología ágil" - gran indicador de desorientación. En primer lugar, hablar de "ágil" como si fuera algo específico, mientras que es un término paraguas muy vago para muchas cosas diferentes. En segundo lugar, el uso de "la" metodología ágil: ¡hay montones de ellos y muchas formas diferentes de hacer muchos de ellos! En tercer lugar, mucha gente en la comunidad ágil llegó aquí en la reacción violenta contra los grandes y pesados métodos cargados de UML de los años noventa. Estas personas no tienden a usar la palabra "metodología" ...
Necesita personas especialmente talentosas para desarrollar software de forma ágil. Jeff Sutherland dice que consideraron usar el modelo del "equipo principal de programadores" para administrar equipos en los bancos, pero descubrieron que no tenían nada como "jefes" suficientes. Scrum está diseñado para obtener la mejor productividad de muchos programadores moderadamente capaces. De hecho, eliminar a un miembro del equipo desproporcionadamente productivo que no quiere ayudar a los demás puede "desbloquear" a los mediocres miembros del equipo y elevar su productividad combinada hasta más que compensar al ex miembro del equipo superproductor ... Eso es lo que Jeff dice de todos modos ...

Hay muchos otros relacionados con XP que se nos ocurrieron en un taller de espacio abierto que http://xpday-london.editme.com/WhereHasXpGone recientemente: http://xpday-london.editme.com/WhereHasXpGone

¿Cuáles son los mitos o conceptos erróneos relacionados con Agile?

Hay muchos conceptos erróneos relacionados con Agile en los que puede caer un recién llegado promedio. ¿Cuáles son los conceptos erróneos en el mundo Ágil y cómo justifica que es realmente una idea errónea?

Actualización: Resumen de mitos ágiles

Agile no permite la documentación
Los métodos ágiles no escalan
Agile significa que no hay plan
TDD cubre todas las necesidades de pruebas de unidades
La programación de pares siempre da como resultado un mejor código
Agile es una solución milagrosa para los problemas de ingeniería de software (hay una solución de bala de plata)
Agile no necesita diseño frontal
Estamos haciendo scrum, por lo que no es necesario hacer TDD, refactoring Pair Programming, etc.
Uno puede aprender ágil de un libro
Agile solo funciona para proyectos triviales
Agile siempre usa "User Stories"

Lea las siguientes respuestas para obtener más información acerca de los mitos anteriores y de más mitos.

"Software de trabajo sobre documentación integral" significa que no necesita una especificación funcional ...

¡¡¡Incorrecto!!! Simplemente significa que puede resolver las arrugas de forma iterativa con los usuarios: hablando como proveedor, aún necesita una buena documentación para ayudar con las fases de control de calidad y cierre de sesión ...

El mito más grande que he visto es que las personas piensan que es mejor que otros procesos de desarrollo.

Es el aceite de serpiente silver-bullet habitual que hemos estado viendo en esta industria durante años.

https://.com/questions/301993/is-agile-development-dead/302060#302060

Gran hilo. Si bien no ofrezco nada nuevo en mi publicación de blog relacionada, sí ilustramos las dos razones principales por las que falla Agile cuando falla. 1) Falta de requisitos iniciales (tomando la ''codificación de inicio con requisitos incompletos'' a un extremo) y 2) Falta de pruebas unitarias adecuadas (porque el CAMBIO ocurrirá, y las pruebas unitarias son la forma más rápida de detectar todos los puntos de ruptura resultantes del CAMBIO).

http://www.anujvarma.com/BlogEngine.net/post/2010/11/03/Agile-versus-Flat-Footed-development.aspx

Mito: "No Big Design Up Front" significa que no hay diseño.

Mito: Agile siempre es una mejor opción en comparación con otras alternativas.

Hecho: dependiendo del tamaño del proyecto, los requisitos (particularmente la flexibilidad de los mismos), el cronograma externo y la actitud del cliente, puede que no siempre sea más productivo en comparación con la metodología ortodoxa.

Mito: Agile significa que no hay documentación

Hecho: software de trabajo de valor ágil más que una documentación completa, pero esto no significa que no haya documentación. La documentación debe escribirse justo a tiempo, y lo suficiente. Y no, Agile no dice que uno siempre debería usar historias de usuarios. ¡Úselos si, y solo, si son apropiados!

Mito: Ágil significa que no hay plan

Hecho: Agile no es compatible con el desarrollo sin planificación. Agile utiliza planificación y estimación continuas para maximizar el ROI. En realidad, Agile tiene que ver con la administración del alcance.

Mito: Agile significa no disciplina

Hecho: los desarrolladores ágiles deben ser más disciplinados para el éxito.

Mito: Agile solo funciona para proyectos triviales

Hecho: Agile (en realidad Scrum aquí) se ha utilizado para

Software de vida crítica aprobado por la FDA para rayos X y MRI,
Aplicaciones de pago financiero,
24x7 con 99.99999% de requisitos de tiempo de actividad,
Aplicaciones de base de datos de varios terabytes,
etc

Mito: Agile no escala

Hecho: Sutherland usó Scrum en grupos de más de 500, Cohn usó Scrum en grupos de más de 100

Mito: debes planear y programar cuidadosamente cada sprint.

Esto te lleva a hacer muchos preparativos iniciales para que puedas planificar completamente cada sprint.

Esto te lleva a derrotar la agilidad y a crear una cascada llamada "Ágil".

Mito: el desarrollo de prueba primero obliga a su proyecto a realizar pruebas unitarias adecuadas.

Hecho: Muchos desarrolladores se vuelven perezosos, y las pruebas de unidad que escriben antes de que su código a menudo sean débiles e inadecuados.

Mito: la programación de pares siempre da como resultado un mejor código.

Hecho: los programadores tienden a ser ligeramente antisociales y tienen procesos de pensamiento significativamente diferentes entre sí. Tener a alguien respirándote en la nuca mientras codificas es muy desagradable, y el resultado suele ser una atmósfera de trabajo tensa con una reducción en la calidad y cantidad del código.

Mito: el uso de prácticas de desarrollo ágiles es una solución milagrosa para los problemas de ingeniería de software.

Mito: la cascada siempre falla.

Realidad: la mayor parte del software que está utilizando en su proyecto ágil se desarrolló con cascada. Incluso la cascada BDUF, en muchos casos.

No hay verdaderos mitos, pero cualquier cosa llevada al extremo será incorrecta. Un proyecto Agile que tiene un diseño cero con la esperanza de "diseñar a medida que avanza" probablemente fallará. Un proyecto de cascada que diseña todo hasta el último punto y coma probablemente fallará debido al presupuesto, el tiempo o los requisitos modificados del usuario.

Se ha dicho en repetidas ocasiones que "los métodos de diseño ágiles no se escalan", mientras que el desarrollo ágil se escalará de forma efectiva a cualquier tamaño si se implementa y se piensa correctamente.

Si no muestra el valor real con ágil, fallará. Y fracasar miserablemente como en bancarrota una empresa miserablemente. Ir ágil solo porque es ''ágil'' te hace parecer tan tonto como el CIO en este video:

http://www.youtube.com/watch?v=nvks70PD0Rs

John

Tienes toda la razón de que hay muchos mitos en torno a Agile, algunos vienen del exterior y otros vienen de adentro. Aquí hay algunos más que pensé agregar a la lista:

"Ya no necesitas gerentes de proyecto o analistas de negocios"

Aunque no estamos haciendo BDUF y los equipos son autodirigidos, a medida que aumentan las cosas todavía hay una necesidad de personas cuyo trabajo coordine lo que está sucediendo. Y si tiene un escenario comercial muy complejo, puede necesitar a alguien que lo ayude a darle sentido. IME, muchos de los proyectos que realmente necesitaban PM y BA todavía los necesitan (y aquellos que no los necesitan ahora, ¡probablemente nunca los necesitaron!). Pero, por supuesto, los roles de los PM y los BA tienden a ser diferentes en el mundo Ágil, y eso puede hacer que las personas se sientan incómodas.

"Agile no se puede usar para proyectos de precio fijo"

Puede, pero es bastante más difícil. Sobre todo porque todos sabemos que "precio fijo" realmente significa "precio fijo, alcance y tiempo" ...

"No hacemos BDUF, lo hacemos todo a medida que avanzamos"

La única forma de trabajar es JEDUF (Just Enough Design Up Front). A veces necesitas más, a veces puedes salir adelante con menos, pero no haces más de lo que necesitas en ese momento.

Es fácil saber qué cobrar a su cliente. Este siempre es el mayor problema para nosotros, ya que no conocemos el alcance del proyecto, no podemos darle un precio fijo al cliente, y la mayoría de los clientes exige un precio fijo.

Mito: Agile es antitético a la seguridad.

Hecho: Esto solo es cierto, si intenta forzar un SDL tipo cascada (ciclo de vida de desarrollo de seguridad) en equipos supuestamente ágiles. De hecho, he diseñado e implementado variantes de Agile-SDL en numerosas organizaciones, y puedo decir que al poner Agile en la seguridad, en realidad puede permitirse un nivel de seguridad más alto y más sólido. solo requiere un cambio en la mentalidad de seguridad, desde el control hasta la visibilidad y la orientación .

Mito : Ágil significa XP y Scrum

Hecho : hay otras prácticas como OpenUP, AMDD, etc.