Ágiles mitos y conceptos erróneos [cerrado]

https://stackoverflow.com/questions/1871110

18-09-2019
|

Pregunta

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

Hay muchas ideas falsas relacionadas con ágil que un recién llegado promedio puede caer. ¿Cuáles son los conceptos erróneos en el mundo ágil y cómo se justifican que es verdaderamente un error?

Actualización: Resumen de los mitos ágil

Agile no permite la documentación
Los métodos ágiles no escalan
ágil significa ningún plan
TDD cubre todas las necesidades de prueba de unidad
Par de programación siempre resulta en un mejor código
Agile es una solución mágica a los problemas de ingeniería de software (Hay una solución mágica)
Agile no necesita hasta diseño frontal
Estamos haciendo scrum por lo que no tenemos que hacer TDD, refactorización la programación en parejas, etc.
Se puede aprender de un libro ágil
Agile sólo funciona para proyectos triviales
Agile siempre utiliza "Historias de usuario"

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

Solución

"Estamos haciendo Scrum - por lo que no necesitamos (par | refactor | do TDD | ...)" En realidad, los fundadores de Scrum - Ken y Jeff han sido diciendo que todos los equipos de scrum de alta productividad implementar toda la gama de prácticas de programación extrema.
desarrollo basado en pruebas no encontrará todos los errores / no es fácil de aplicar a todo - por lo que no vamos a tratar - Aprender TDD no es una "todo o nada acuerdo" y que vaya mejor en lo que a juzgar a probar y cómo hacerlo de manera eficiente. Yo he estado haciendo desde hace diez años y todavía estoy encontrar mejores maneras de hacerlo y nuevas cosas a tener en cuenta.
Puedo aprender todo lo que necesito para aplicar los métodos ágiles de un libro - Tienes que aprender sobre la marcha y que a menudo significa entrenar y conocer a otras personas que pueden ayudar. Muchas cosas van mal cuando la gente sólo trata de aprender de un libro.
histérica (y bastante real) "El candidato debe tomar la dirección de, y apoyar el scrum master" (De una especificación de trabajo me enviaron la semana pasada ...) - El scrum maestro no debe decirle a la gente qué hacer . Él / Ella está allí para facilitar - es decir, para ayudar al equipo a aprender a ordenar las cosas ellos mismos. Es un modo de falla masiva - tener un scrum master "comandos" que la gente
Hablando de "la metodología ágil" - indicador de gran despiste. En primer lugar, hablar de "ágil" como si fuera una cosa específica, mientras que es un paraguas términos muy vagos para muchas cosas diferentes. En segundo lugar, el uso de "la" metodología ágil - hay un montón de ellos, y un montón de diferentes maneras de hacer muchas de ellas! En tercer lugar, mucha gente en la comunidad ágil llegó aquí en la reacción contra los grandes métodos, UML-cargados de los años noventa. Estas personas no tienden a usar la palabra "metodología" ...
Es necesario pueblos especialmente dotados para desarrollar software de la manera ágil Jeff Sutherland dice que consideraban utilizando el modelo de "jefe de equipo programador" para la gestión de equipos en los bancos -., Pero encontraron que dejase' t tiene nada parecido suficiente "jefes". Scrum está diseñado para obtener la mejor productividad de una gran cantidad de programadores capaces moderadamente. De hecho la eliminación de uno, de manera desproporcionada a los miembros del equipo de producción que no quiere ayudar a los demás pueden los miembros del equipo mediocre "desbloquear" y llevar su productividad combinada de hasta más de compensar la ex miembro súper productiva equipo ... Eso es lo que Jeff dice de todos modos ...

Hay un buen número de otros relacionados con los XP que se nos ocurrió en un taller de espacio abierto que me llevó recientemente: http://xpday-london.editme.com/WhereHasXpGone

Otros consejos

"El software de Trabajo más de una documentación completa" significa que no es necesario una especificación funcional ...

incorrecto !!! Sólo significa que se puede limar las arrugas de forma iterativa con los usuarios - en su calidad de proveedor, usted todavía necesita una buena documentación para ayudar en el control de calidad y cierre de sesión fases ...

Mito: el uso de prácticas de desarrollo ágil es una solución mágica a los problemas de ingeniería de software.

Mito: Ensayos primer desarrollo de su proyecto obliga a tener pruebas de unidad adecuada

Hecho:. Muchos desarrolladores da pereza, y las pruebas de unidad que escriben antes de su código son a menudo débil e insuficiente

Mito:. Par de programación siempre resulta en un mejor código

Hecho: Los programadores tienden a ser ligeramente antisocial y tener significativamente diferentes procesos de pensamiento entre sí. Tener a alguien respirando en su cuello a medida que el código es muy desagradable, y el resultado es a menudo un ambiente de trabajo tenso con una reducción en la calidad y cantidad de código.

Mito: ágil significa que no hay documentación

Hecho: software que trabaja valor más ágil documentación completa, pero esto no significa que no hay documentación en absoluto. La documentación debe ser escrito justo a tiempo, y sólo lo suficiente. Y no, ágil no decir uno debe siempre utilizando historias de usuario. Usarlos si, y sólo, si son apropiados!

Mito: ágil significa ningún plan

Hecho: ágil no es compatible con el desarrollo sin planificación. Ágil utiliza planificación continua y la estimación para maximizar el retorno de la inversión. En realidad, se trata ágil gestión del alcance.

Mito: ágil significa que no hay disciplina

Hecho:. Ágiles desarrolladores tienen que ser más disciplinado para el éxito

Mito: Agile sólo funciona para proyectos triviales

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

aprobado por la FDA, el software de la vida crítica para las radiografías y resonancias magnéticas,
pago financiero,
24x7 con los requisitos de tiempo de actividad 99.99999%,
aplicaciones de bases de datos de varios terabytes,
etc.

Mito: Agile no escala

Hecho: Sutherland utiliza Scrum en grupos de 500+, Cohn utiliza Scrum en grupos de 100 +

Mito: "No Big Diseño Frente Hasta" significa que no hay diseño

Mito:. Cascada siempre falla

Realidad: La mayoría del software que está utilizando en su proyecto ágil fue desarrollado con cascada. Incluso cascada BDUF, en muchos casos.

No hay mitos reales - pero nada llevado al extremo habrá equivocado. Un proyecto ágil que hace diseño de cero con la esperanza de "diseñar a medida que avanza" probablemente fallará. Un proyecto de la cascada que diseña todo, hasta el último punto y coma probablemente fracasará por falta de presupuesto, el tiempo o las necesidades del usuario cambiado.

Se ha dicho repetidamente "ágiles métodos de diseño no se adaptan", mientras que el desarrollo ágil se escala con eficacia a cualquier tamaño si se ejecuta y pensado correctamente.

Mito: Es necesario planificar y programar cuidadosamente cada sprint

Esto le lleva a hacer montones y montones de planificación por adelantado para que pueda planificar totalmente cada sprint.

Esto conduce a derrotar agilidad y crea una cascada llamada "ágil".

El mito más grande que he visto es que la gente piensa que es mejor que otros procesos de desarrollo.

Es la costumbre de bala de plata de aceite de serpiente que hemos estado viendo en esta industria desde hace años.

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

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

Hecho:. Dependiendo del tamaño del proyecto, los requisitos (particularmente flexibilidad de tal), el horario externo, y la actitud del cliente, puede no siempre ser más productivos en comparación con la metodología ortodoxa

Mito : ágil significa XP y Scrum

Hecho . Hay otras prácticas como OpenUP, AMDD, etc.

Es fácil saber cuánto cobrar a su cliente. Este es todos los días los mayores problemas para nosotros, porque no sabemos el alcance del proyecto no podemos dar al cliente un precio fijo , y la mayoría de las demandas de los clientes un precio fijo.

Gran hilo. Mientras que ofrezco nada nuevo en mi blog relacionado, yo ilustrar los dos principales razones por las ágil falla cuando no falle. 1) La falta de requisitos iniciales (tomando la 'comienzan codificación con los requisitos incompletas' a un extremo) y 2) La falta de pruebas unitarias adecuadas (ya que el cambio será efectivo -. Y pruebas unitarias son la forma más rápida de la captura de todos los puntos de ruptura resultantes del cambio)

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

tienes toda la razón que hay una gran cantidad de mitos en torno ágil, algunos que vienen de fuera, y otros desde el interior. Éstos son algunos más pensaba en añadir a la lista:

"No es necesario administradores de proyectos o analistas de negocios más"

A pesar de que no estamos haciendo BDUF y equipos son auto-dirigido, como la escala de las cosas todavía hay una necesidad para las personas cuyo trabajo está coordinando lo que está pasando. Y si tiene un escenario de negocio muy complejo, así que puede necesitar a alguien para ayudar a encontrar el sentido de la misma. IME, muchos de los proyectos que el SPM y Bas realmente necesarios todavía los necesitan (y los que no los necesita ahora, probablemente nunca los necesitaba!). Pero, por supuesto, las funciones de los PMs y Bas tienden a ser diferentes en el mundo ágil, y que pueden hacer que la gente incómoda.

"ágil no puede ser utilizado para proyectos de precio fijo"

Puede, pero es un poco más difícil. Sobre todo porque todos sabemos que el "precio fijo" en realidad significa "precio fijo, el alcance y el tiempo" ...

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

La única manera de trabajar es JEDUF (Just Enough Diseño de frente). A veces se necesita más, a veces puede llegar a funcionar con menos, pero no haces más de lo necesario en ese momento.

Mito: Agile es anti-thetical a la seguridad.

Hecho: Esto sólo es cierto, si se intenta forzar una SDL-estilo de cascada en toda regla (la seguridad del ciclo de vida de desarrollo) en los equipos supuestamente ágiles. De hecho, he diseñado e implementado variantes Agile-SDL en numerosas organizaciones, y puedo decir que poner el ágil en de la seguridad, en realidad se puede permitir un nivel más robusto más alto de seguridad. sólo se necesita un cambio de mentalidad en seguridad - de Control a visibilidad y orientación .

Si no se presenta el valor real con ágil, se producirá un error. Y fracasan miserablemente como en una empresa en quiebra estrepitosamente. Ir a Agile sólo porque es 'ágil' te hace parecer tan tonto como el CIO en este video:

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

John

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow