¿Es Agile la nueva microgestión?


80

Esta pregunta se ha estado cocinando en mi cabeza por un tiempo, así que quería preguntar a aquellos que siguen prácticas ágiles / scrum en sus entornos de desarrollo.

Mi empresa finalmente se aventuró a incorporar prácticas ágiles y comenzó con un equipo de 4 desarrolladores en un grupo ágil a modo de prueba. Han pasado 4 meses con 3 iteraciones y continúan haciéndolo sin ser completamente ágiles para el resto de nosotros. Esto se debe al hecho de que la gerencia confía en cumplir con los requisitos comerciales con una solicitud de tipo ad hoc desde arriba.

Recientemente, hablé con los desarrolladores que forman parte de esta iniciativa; Me dicen que no es divertido. Su maestro Scrum no les permite hablar con otros desarrolladores y no pueden recibir llamadas telefónicas en el área de trabajo (lo cual puede estar bien hasta cierto punto). Por ejemplo, si quiero hablar con mi amigo por patadas que está en el equipo ágil, no se me permite sin la aprobación del maestro Scrum; quien está sentado justo al lado del equipo ágil.

La idea de todo esto o lo ágil es proporcionar un vacío completo a los desarrolladores ágiles de cualquier interrupción y hacer que pasen más de 6 horas productivas. Bueno, muchachos, no soy un gurú ágil, pero lo que he leído el documento de despliegue ágil de Yahoo y similar para otras organizaciones, me da la sensación de que ágil no es barato. Requiere recursos y presupuesto para inculcar a los equipos con agilidad y corregir el problema a medida que llegan para volver a encaminarlos.

Para empezar, requiere capacitación para desarrolladores y capacitación para gerentes, etc. El actual Scrum master era un gerente que tomó un par de días de clase de capacitación ágil pagada por la gerencia y ahora dirige este equipo ágil. También he escuchado en la reunión que el manifiesto ágil no dicta que el ágil no esté escrito en piedra y se personalice de manera diferente para cada empresa. Bueno, todo suena bien y razón.

En conclusión, siempre pensé que se suponía que el ágil traería armonía en los equipos de desarrollo, lo que da como resultado desarrolladores felices. Sin embargo, tengo una sensación muy opuesta cuando hablo con los desarrolladores del equipo ágil. No están contentos porque no pueden hablar más que trabajar, se sientan en silencio todo el día solo trabajando, y sienten que es solo otra forma para que la gerencia los haga trabajar más.

Dígame, por favor, si este es uno de los ejemplos de buenas prácticas utilizadas con el fin de obtener una ventaja egoísta por más dólares. O tal vez, solo somos nosotros los desarrolladores como yo y este equipo ágil siente que no les gusta trabajar en un entorno donde solo respiran porque están en el trabajo.


Es una empresa en el dominio de la salud que tiene oficinas en los Estados Unidos. Definitivamente se siente como un ágil estilo vaquero, lo que me hace realmente no querer ir para ágil en absoluto, especialmente en mi empresa actual.

Todo tiene que ver con que la administración sea completamente barata. Recorte el café caro para una versión más barata, enfatice el ahorro y sea productivo mientras se mantiene lo más delgado posible.

Mi sensación es que alguien en la gerencia detrás de la puerta rechazó esta idea, esa agilidad te hace producir más para que podamos mostrar a nuestros jefes que estamos produciendo más con el mismo personal. O, tal vez, nos permitirá reducir el personal si ese es el caso.

Están teniendo su reunión diaria de 5 minutos. Pero no está permitido chatear o hablar con alguien fuera de su equipo. Todo el foco está en el trabajo.


71
He visto más abusos en nombre de ágil de los que me gustaría comentar. Muchas veces "estamos haciendo ágil" significa "estamos desechando toda apariencia de proceso y haciendo lo que queremos, Yeehaw!" (para la referencia obvia del vaquero). Un entorno tranquilo definitivamente ayuda, pero que tienen para permitir a los desarrolladores para hablar unos con otros y de martillo cosas fuera - sin scrum dictador aprobación.
Berin Loritsch

28
Bueno, no estás haciendo Agile ...
CaffGeek

13
Esto es realmente un discurso. No es una pregunta
JohnFx

8
2 días en el curso de scrum master certificado no convierte al administrador en un scrum master, al igual que las 24 horas con autoaprendizaje de c ++ en 24 horas no lo convierten en un programador capaz de c ++. Simplemente lo están haciendo mal.
Matt

99
lectura requerida: Manifiesto Ágil Medio Arsed "Hemos escuchado sobre nuevas formas de desarrollar software pagando a consultores y leyendo informes de Gartner ..."
mosquito

Respuestas:


89

Estás describiendo una dictadura gerencial, no ágil. Agile trata sobre el desarrollo incremental en un campo de requisitos cambiantes, no sobre dictar a las personas cómo hacen individualmente su trabajo.


77
Lo único cercano que pude encontrar fue una publicación de "Joel on Software" en las 12 cosas principales que toda empresa debería proporcionar a sus programadores. Uno de los 12 era un lugar tranquilo para trabajar. Sin embargo, dudo que Joel Spolsky haya querido decir esto.
Berin Loritsch

55
Un lugar de trabajo tranquilo sería aquel en el que, si no tiene una conversación, las cosas son generalmente tranquilas y donde puede tener una conversación sin molestar a los demás. Eso significa que no existe una cultura de búsqueda de personas a través del intercomunicador, y el uso de generadores de ruido blanco u otros métodos para minimizar el nivel aparente de sonido en áreas donde trabaja mucha gente. Una regla de no hablar no hace un lugar de trabajo tranquilo.
Kevin Cathcart

55
@Kevin Cathcart, estamos en un acuerdo violento sobre eso. Ahora, he estado en una compañía donde sucedía lo contrario. Teníamos ~ 40 personas en un bullpen con mesas abiertas y sin cubos. El único equipo que pudo hacer algo fue el que hizo la mayor parte del ruido. Ese es el tipo de entorno contra el que desea protegerse.
Berin Loritsch

8
@Kevin: mi departamento de desarrollo es una granja de cubículos abiertos, justo al lado de una serie de tres campanas etiquetadas como "Venta", "Gran venta" y "Gran venta". Unas pocas veces al día, los vendedores los llaman y gritan "¡guau!". : - \
Dan Ray

2
@¡Dan tuve una serie de entrevistas hace unos años donde tres startups me dijeron que tenían que alejar a los vendedores de los desarrolladores porque ellos también lo estaban!
Erik Reppen

46

El maestro Scrum no les permite hablar con otros desarrolladores y no pueden atender ninguna llamada telefónica en el área de trabajo.

Esto realmente no es parte de las prácticas ágiles, y es un tema separado.

Una gran motivación de las metodologías ágiles es una mayor comunicación entre los desarrolladores. Restringir la comunicación del desarrollador <-> desarrollador es un problema separado de las prácticas ágiles. No estoy diciendo que esto no esté sucediendo, obviamente lo está, y está siendo etiquetado como parte del despliegue "ágil" en su organización, pero este es realmente un problema separado de ágil (y algo en contra del espíritu de desarrollo ágil, OMI).


29
Está absolutamente en contra del primer principio del Manifiesto Ágil: "Individuos e interacciones sobre procesos y herramientas". Ver agilemanifesto.org para más información.
Berin Loritsch

"Está absolutamente en contra del primer principio del Manifiesto <XXX>"; reemplace cualquier cosa por XXX, y tendrá su culto de elección. ;-) En serio, ¿no te hace pensar esto?
CesarGon

55
@CesarGon, en este caso estamos hablando de los principios de lo que hace que el trabajo ágil. Si no puede atribuirse a los principios básicos de ágil, entonces quizás no quiera ágil. Bastante simple. No digo "convertir a la fe", digo "haz lo que dices que crees". En serio, ¿ eso no te hace pensar?
Berin Loritsch

1
@CesarGon, lo que describió el OP es sobre el polo opuesto de la intención de esa guía como puede obtener. ¿En qué punto consideras que tu tono medio está lo suficientemente cerca? La forma en que habla suena como una diferencia del 95% entre los tonos es lo suficientemente cercana. Vamos. Y dame un poco de crédito. He estado trabajando en el mundo real y definiendo procesos en corporaciones durante mucho tiempo. Entiendo muy bien lo que está lo suficientemente cerca, y lo que el OP describió no es eso.
Berin Loritsch

2
@Berin Loritsch: te doy crédito; No era mi intención aparentar lo contrario. Mi comentario inicial acerca de los cultos trató de sonar parcialmente bromista, en realidad. El punto que estoy tratando de hacer es que no necesitamos algunas líneas en un manifiesto para defender algo que es abiertamente contra el sentido común. El OP describe una situación que hace sonar todas las alarmas. Espero que lo tomes bien; lo siento si fui demasiado duro. :-)
CesarGon

31

Eso suena como una implementación bastante perversa de ágil. Ágil, en todo caso, debería reducir la microgestión, no aumentarla. El equipo se compromete y parte del proceso es que la gerencia confía en que el equipo lo logrará. El scrum diario es una forma para que los desarrolladores se comuniquen entre sí y una forma de informar lo que hicieron, no cómo pasaron su tiempo (lo cual es un error que he visto en algunos lugares). Incluso el proceso de estimación debería eliminar el tiempo explícito de las estimaciones, ya que debe estimar la complejidad relativa, no cuánto tiempo llevará una historia (otro error común). Controlar el tiempo dedicado por los desarrolladores es el sello distintivo de la microgestión, y eliminar el tiempo del proceso es uno de los principios básicos de Agile.


24

El entorno que describe suena como una variedad de jardín pseudo-Agile bullshit .

Me involucré con Agile antes de que fuera Agile. Alrededor de 2000, me estaba agotando la codificación, escuché sobre la Programación Extrema, la probé y me gustó. Como desarrollador, me dio un contexto en el que la producción de software sólido era lo más importante, y me dio herramientas para minimizar muchas de las tonterías que me estaban volviendo loco. Me encantó.

El problema hoy en día, lo que explico en detalle en otra parte , es que la mayoría de las personas que adoptan "ágil" en estos días no están interesados en la mejora de nada si los hace sentir incómodos. Entonces, para ellos, "Agile" es solo un nuevo palo para vencer a los desarrolladores de la misma manera. A diferencia de, por ejemplo, una forma de aumentar radicalmente la productividad mientras se eliminan todas las tonterías que están ralentizando el desarrollo.

Ahora mismo. Estoy comenzando una compañía, y usaré muchos XP, además de otros trucos que aprendí en el mundo Ágil. Pero precisamente por historias como la suya, me estremezco cada vez que escucho sobre una adopción ágil en estos días.

Entonces, para responder a su pregunta directamente: Agile no debería ser la nueva microgestión. Debería tratarse de empoderar a las personas que hacen el trabajo real para hacer una mierda. Pero en su caso, Agile suena como la última mentira que le están diciendo mientras se complacen con sus propios malos instintos. Por lo cual realmente lo siento.


44
+1. Ágil / scrum / xp o lo que sea son términos "mumbo jumbo" para tiendas de TI que no son compañías de software reales. Como dijiste, nadie puede hacer cambios radicales mientras entierra su cabeza en la arena con estas prácticas. Todo lo que necesita leer es este gran desarrollo de software Lean: un kit de herramientas ágil y dejar atrás todas las BS. Estas prácticas no son para tiendas de TI es mi conclusión.
Smith James

23

Esto no es ágil.

En primer lugar, Scrum no es ágil . Scrum, francamente, es una mierda. Fui criado en una casa de Programación Extrema (literalmente, hice que Kent Beck se sentara en el sofá de mi padre y me hablara sobre las pruebas), y puedo decirte que Scrum no lo es. Scrum es una herramienta de gestión de proyectos: un ritmo definido para un proyecto de desarrollo. Pero no tiene nada que decir sobre el desarrollo en sí, y muy poco que decir sobre los requisitos, la planificación y la relación con el cliente. XP tiene mucho que decir sobre todo eso; Cualquier otra metodología que quiera llamarse ágil debe tener algo que agregar a la conversación. Los defensores de Scrum lo han descrito no como un proceso, sino como un contenedor para un proceso. Un hombre sabio señaló una vez que un envoltorio es lo que se quita y desecha para llegar a lo bueno.

¡Bien, scrum despotricando!

En segundo lugar, un principio fundador de XP, que creo que es fundamental para cualquier proceso ágil, es que se centra en el desarrollador . Es una forma de dar a los desarrolladores el poder de hacer el trabajo que saben que deben hacer, y con tanta frecuencia se les impide hacerlo. Un equipo ágil puede estructurarse como una democracia o una autocracia, pero los líderes son desarrolladores. Hay roles para gerentes de proyectos y demás, roles vitales, pero no es uno de liderazgo de equipo. Tener un gerente, lo siento, 'scrum master', sentado allí dando órdenes a la gente es una señal segura de que el equipo no está siendo ágil.

Siento que debería haber un tercero. No hay


-1, no estoy de acuerdo. El desarrollo ágil también significa que purifica y facilita los procesos y también la capacidad de adaptarse a los cambios. Lo cual es exactamente de lo que se trata Scrum. Scrum también se trata de requisitos y planificación, de manera diferente.
Falcon

66
Eh, vamos, esto es 2012. Cita la escritura pública de Kent Beck o déjalo. No importa si se aplastó en tu sofá.
nes1983 15/12/12

66
@ nes1983: Escribí eso en 2011. Las cosas eran diferentes entonces.
Tom Anderson

3
Nunca escuché el término "deuda técnica" hasta que el scrum apareció en mi radar. He estado en el entrenamiento. El aceite de serpiente de venta fácil pretende atraer a la gerencia a expensas de consideraciones de calidad del producto a largo plazo. 100% mierda. Aunque me lo tragaría totalmente si los Scrum Masters llevaran una espada de estilo Conan para golpear a las personas que amenazaban la integridad del proceso.
Erik Reppen

2
+1 para el despotricar Scrum. Pienso en Scrum como la metodología "ágil" para las personas a las que les gusta tanto la cascada que quieren hacerlo cada dos semanas.
Kyralessa

16

Scrum es el hijo bastardo de Agile. Es el estilo más cascada de todas las metodologías ágiles, y es por eso que es el más popular entre los gerentes.

Todos los métodos ágiles tienen que ver con la producción de código de trabajo sin que se interfieran. Lee eso de nuevo. Y otra vez.

Cualquier cosa que se interponga en el camino de ese objetivo, independientemente de las "reglas ágiles" es malo. Si las reglas se interponen, ¡cambie las reglas f * * ! Esa es la forma ágil, eso es lo que lo hace relevante y efectivo.

El mejor ejemplo de esto lo da Alistair Cockburn (uno de los creadores del manifiesto ágil):

“Ponga a 4-6 personas en una sala con estaciones de trabajo y pizarras blancas y acceso a los usuarios. Haga que entreguen software probado y en ejecución a los usuarios cada uno o dos meses, y de lo contrario déjenlos en paz "

Si eso funciona para la calidad de los chicos que tienes, entonces eso es todo lo que necesitas. No necesita un scrum master ni ninguna metodología "ágil". Si sentarse en un scrum diario funciona para usted, entonces f * * * hágalo. Hacerles ponerse de pie es simplemente una patética abrogación de su capacidad de pensar por sí mismos.

Hay una respuesta al tipo de agilidad que estás haciendo. Es esto. Imprímalo y péguelo en algún lugar cuando no haya nadie más y déjelo descubrirlo por sí mismo.


Haga que entreguen software probado y en ejecución a los usuarios, ¿quiere decir que cada 2/3 semanas?
user272671

2
@ usuario272671 NO. Haga que entreguen software ejecutado y probado al usuario regularmente. No en un horario estúpidamente arbitrario como 2 o 3 semanas. Si los usuarios o la complejidad del software es tal que un ciclo de trabajo de 6 semanas, entonces haga 6 semanas. Si se puede hacer en un "cuando se complete", entonces hazlo. No te hagas isquiotibiales con restricciones artificiales. Tal no es ágil.
gbjbaanb

11

El actual maestro Scrum era un gerente que tomó un par de días de clase de capacitación ágil pagada por la gerencia y ahora dirige este equipo ágil.

Ese es tu problema. Los directivos quieren algo ágil, realmente no saben qué es, y se lo imponen a los equipos. Eso es más o menos lo que debe hacer cuando desea disminuir significativamente la productividad de sus desarrolladores;)

La nueva propuesta de proceso debería provenir de los desarrolladores. O al menos ser revisado y aprobado por ellos si es una idea de la gerencia.

En cualquier caso, si los desarrolladores lo rechazan, ¡no lo implemente ! O será el desastre que describas.


9

Con frecuencia se abusa de la "metodología de gestión" "ágil" y de cualquier otra para forzar la microgestión en las personas. OTOH también a veces se abusa de defender la mala mano de obra.

"Somos ágiles" es la excusa más frecuente que escucho por falta de planificación, falta de pensamiento sobre diseño, características, calidad, ciclos de lanzamiento. Esto generalmente de los desarrolladores y la gestión inferior. Es una locura también la excusa más utilizada que escucho de los gerentes intermedios, arquitectos, vendedores, etc. para microgestión, plazos de entrega y listas de características siempre cambiantes, lo que obliga a las horas extraordinarias a las personas (los plazos de entrega y listas de características siempre cambiantes aseguran eso, por supuesto), etc. etc. .

Los dos, por supuesto, a menudo están en contradicción directa, y pueden suceder en el mismo proyecto.


En mi experiencia ... solo escuché una introducción ágil (siempre scrum) para explicar la microgestión. No lo negaré, es un estilo diferente y único de microgestión. Nunca escuché a un desarrollador decir que son ágiles, y explicar una breve venida. ¿Qué tipo de gestión de scrum forzado has experimentado?
JM Becker

1
cada vez que me encuentro con scrum, se introdujo porque un gerente (generalmente más alto que el gerente de proyecto) había escuchado que era "la cosa".
Jwenting

7

Para responder a su pregunta original, ¿es Agile la nueva microgestión? Yo diría que no.

En primer lugar, ir a leer esto (manifiesto ágil) y se dará cuenta de que no hablar con sus compañeros de los desarrolladores no está en la lista.

En realidad, "Individuos e interacciones" es exactamente lo contrario de no hablar con sus co-desarrolladores.


Bueno, "Individuos e interacciones" son lo que están haciendo ahora mismo dentro de su equipo. ¿Cómo va en contra del manifiesto ágil, si miras desde el punto de vista maestro de Scrum? El problema en este momento es que no deben interactuar con otros equipos para mantener su productividad, lo cual es la causa de las quejas del grupo ágil.
Smith James

No están interactuando Ese es el problema. Seguro que un desarrollador puede abusar de los privilegios y hablar sobre cosas sin sentido durante horas. Sin embargo, la mayoría de los buenos desarrolladores quieren entregar un proyecto de calidad. Es una cuestión de orgullo. Todo lo que el scrum master está haciendo socava eso y, en cambio, lo convierte en una cuestión de represión. De esto no se trata ágil. Un scrum master debería permitir al equipo ser productivo, no romper un látigo y decirles que sean productivos. Ellos ya quieren ser productivos.
Berin Loritsch

2

Ágil debería ser la nueva autogestión. Si ágil se practica correctamente, muchas de las decisiones son tomadas por un cliente y desarrollador que trabaja una historia de usuario de alcance razonable que se agrega al trabajo a medida que se identifican las tareas.

El scrum diario se trata de comunicación, no de gestión. Habrá algunas discusiones sobre prioridad y equilibrio de carga, pero es de esperar que la persona administrada en el scrum sea el maestro de scrum. Como desarrollador, asisto, digo lo que hice, lo que voy a hacer y qué ayuda necesito. Entonces, el scrum master debería ponerse en acción y eliminar los impedimentos para mi progreso.

Los equipos ágiles no deben sentir que el trabajo diario se gestiona jerárquicamente. Si las decisiones se toman desde lejos por alguien en la cima de una organización jerárquica, ¡es hora de descentralizar la toma de decisiones! Para algunas personas y algunas organizaciones, esto puede ser un puente demasiado lejos. Si lo siguiente no es cierto para su organización:

Vive el Manifiesto Ágil

"Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo".

Evite "Conozca al nuevo jefe, igual que el antiguo jefe". Originar Agile desde dentro del equipo tanto como sea posible. A veces esto sucede al elegir una coalición de personas dispuestas a participar en un proyecto de prueba con Agile. Si puede formar su equipo Agile a partir de voluntarios o miembros invitados que tengan un historial de buen trabajo en equipo, pueden resolverlo. Use un equipo pequeño en un proyecto corto, tal vez para un cliente interno o altamente accesible.

Abraza el cambio. Tal vez pueda tomar algo de capacitación, pero tal vez su presupuesto sea ajustado y el dinero simplemente no esté allí. Otras oportunidades también pueden proporcionar mejoras. Lea un poco, haga que los miembros del equipo aprendan lo que puedan sobre Agile y se enseñen mutuamente. Es posible que pueda encontrar personal nuevo o existente calificado para modelar y liderar la adopción ágil.


1

Los equipos ágiles son como los equipos de fútbol que trabajan para alcanzar un objetivo comúnmente entendido. He sido parte de equipos ágiles durante algunos años y la clave es una comunicación efectiva y eficiente entre todos los interesados. Los gerentes / maestros de Scrum son meros facilitadores del equipo y la gestión tradicional / microgestión matará el espíritu del equipo.

En los equipos en los que he trabajado, se nos anima a jugar juegos de equipo después del horario laboral para mejorar la camaradería entre los miembros. He recogido esos pensamientos aquí .


1
Desarrollar relaciones laborales después del trabajo. Debemos desarrollar nuestras relaciones familiares y de amigos a menudo descuidadas después del trabajo. Teniendo en cuenta que los compañeros de trabajo rara vez son amigos, aprovechan la mayoría de las oportunidades para ayudarse a expensas de otros. La compañía sí, hombres, compinches y herramientas simplemente no se dan cuenta, porque las oportunidades son poco frecuentes. XP podría tener algún valor, no tengo experiencia para decir lo contrario. Scrum se ha convertido en una versión diferente de la microgestión, al menos en las 3 compañías que la conozco. .... Ya sabes qué, odio demasiado a las corporaciones estadounidenses como para ser un poco objetivas.
JM Becker

0

Para responder a su pregunta: No. Agile no es una forma de microgestión. Pero como cualquier herramienta, las personas pueden usarla incorrectamente. Agile es maravilloso cuando se implementa correctamente y cuando las personas son consistentes con él.

Mis pensamientos sobre el tema "Los desarrolladores no hablan con nadie más que con el scrum master":

He trabajado en un lugar donde antes era una regla. SIN EMBARGO, la regla se relacionó más con pedirle a la gente que completara tareas. Por ejemplo, no puedo ir al azar a un probador de desarrollo y pedirle que haga algunas pruebas por mí en las próximas horas. Necesito hablar con el maestro scrum para que puedan discutir con el miembro de su equipo cómo ese trabajo encajará en el sprint si se trata de una emergencia (o si es necesario llevarlo a la cartera de pedidos para un sprint futuro).

En ese caso, entendí el concepto de "desarrolladores que no se hablan entre sí" porque realmente se tradujo en canalizar tareas a través de un punto de control para que un desarrollador en particular no trabaje demasiado o esté tan ocupado haciendo tareas de emergencia que no pueden obtener su planificado trabajo hecho.

De lo contrario, los desarrolladores DEBEN estar hablando entre ellos. Siempre. Le ayuda a resolver los problemas más rápido, a acercarse como equipo y a entregar más rápido.

Solo para ofrecer otra perspectiva: también he estado en un entorno donde la gente pensaba que los desarrolladores "hablaban demasiado". Después de una sesión, descubrimos que en realidad traducido a "los desarrolladores no son lo suficientemente independientes como para hacer su propio trabajo. Debido a que todo está tan fragmentado, los desarrolladores tienen que ir a otras tres personas para completar una pequeña tarea".

Entonces, cuando los gerentes decidieron pasar a ser ágiles, esperaban que eso ayudara a llevar información a los lugares correctos y frenar gran parte de la fragmentación dentro de la organización. Algunas personas estaban un poco decepcionadas de que después de que se implementara Agile, los desarrolladores aún corrían de un lado a otro. Pero, de lo que no se dieron cuenta es que eso estaba sucediendo cada vez menos. Tomó tiempo sin embargo. Por lo tanto, tal vez si eso es lo que está sucediendo en su organización, podría ser que la gente espera que sea ágil arreglar las cosas de la noche a la mañana. Esa no es la forma en que funciona.


-1

El autor original Smith Janes podría haber dado experiencia. Pero estos son los problemas típicos que encontré en el proyecto Agile.

  1. Se supone que la mayoría de las organizaciones, desarrolladores, trabajan en proyectos múltiples, en Agile / scrum. Los sprints nunca se consideran este hecho. su Scrum Master asume que debe terminar con sus historias al final del sprint ... Su Scrum master podría estar dedicado a un solo proyecto, pero no a los desarrolladores ... ESTA ES LA DISTRACCIÓN: no es necesario que solo atienda una llamada telefónica o permitir una llamada telefónica.
  2. He visto proyectos ágiles donde Sprint está planeado, historias incluidas en Sprint, sin estar acurrucados ... a mitad o mitad de los sprints ... desarrolladores que encuentran dependencias no resueltas, requisitos o historias no narradas ... Esto Es uno de los abusos en los proyectos más ágiles.
  3. Pruebas: TTD ... sí, es muy bueno ... pero he visto que la mayoría de los proyectos Agile dependen totalmente de TTD ... no se permite el alcance ni el tiempo para pruebas funcionales o humanas ... Otro abuso ... Muchos Scrum Masters también No sé ni entiendo la importancia de las pruebas funcionales. Su código podría funcionar perfectamente, si no sirve a la necesidad comercial ... no sirve de nada ... Esto sucede cuando las empresas no participan con mucha anticipación ... o la participación está ahí ... pero no refleja la toma de decisiones comerciales Al final, se culpa a los desarrolladores, no entregaste la funcionalidad ... o terminará con un cambio de último minuto ... horas extra largas porque tu Scrum master no quiere culpar por la historia no completada.

Abusar aquí ... ya sea una baja participación de la empresa o un participante que no tiene todos los conocimientos o una persona de negocios que abandona en medio del sprint.

  1. No todos los proyectos son aptos para Agile ... La mayoría de los gerentes o maestros de scrum no lo saben. Proyectos de mantenimiento. Inicialmente se puede asumir que un defecto se puede hacer en 8 horas, aceptado en el sprint. Después de pasar 4 horas, descubrí que esto es Java / otro producto ... (recientemente me enfrenté a un defecto relacionado con el Programador de cuarzo ... dentro de nuestro proyecto) y este defecto podría conducir a la actualización del producto / paquete ... tratar con burocracia, aprobación, la financiación, la nueva versión o la actualización deben ser aprobadas por Ingeniería Interna, etc., 5.Retrospección: solo unos pocos proyectos Ágiles realizan este paso.
  2. Emparejamiento ... Muchos desarrolladores tratan el emparejamiento como un lugar para abusar de los compañeros de trabajo ... critican otros diseños, prácticas de codificación ... el calificador trata como trabajo en equipo., Aprenden unos de otros ... Otra forma de abusar de Agile / Scrum.

Ágil es definitivamente una buena metodología. A menos que su organización no siga completamente o no esté entrenada ... Se abusa ... efectos secundarios 60+ horas de trabajo / semana, juego de culpa, baja moral.


vea este enlace ... por qué los proyectos ágiles fallan ... brighthubpm.com/agile/55778-why-do-agile-projects-fail
mukunda

Estoy de acuerdo con la información presentada en ese artículo allí también. Entiendo que hay quienes piensan que Agile es infalible, pero la realidad es que Agile deja poco o ningún espacio para la introducción de ideas nuevas y más efectivas. is..brighthubpm.com / agile / 55778-why-do-agile-projects-fail
user272671

-3

Ágil es la microgestión disfrazada. No hay lugar para la iniciativa o la creatividad en Agile, ha eliminado la diversión de la programación para permitir a los gerentes incompetentes mantener el control incluso sin tener una idea desde el punto de vista técnico.


2
No podrías estar más equivocado. En ágil, los equipos deben tener una gran cantidad de control creativo. Agile requiere una cantidad extrema de iniciativa, ya que es el equipo el que decide cómo implementar cada historia. La administración en realidad tiene muy poco control sobre el proceso ágil. Personalmente, los tres equipos ágiles diferentes de los que he formado parte han sido extremadamente divertidos. Parece que has experimentado una incompetencia severa que se autoidentificó como ágil sin estar cerca de ser ágil.
Bryan Oakley

agregue un poco de razonamiento para apoyar su afirmación (lo cual tiene cierto sentido para mí pero eso no importa), y eliminaré el voto negativo
mosquito

1
Estoy de acuerdo con @Geo. Hasta la fecha, esa es la impresión que tengo de lo que es "Agile", en el mundo real. Cuando tiene tal configuración en el piso de la fábrica, es simplemente una forma de microgestión. Ahora el Manifiesto intenta decirnos que no es así. Pero proyecto tras proyecto, me hacen creer aún más que es simplemente otro nombre para "Micromanagement". Y mata la creatividad.
user272671
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.