¿Utiliza Agile para un equipo no técnico durante más de un año? ¡Cuentame tu historia!

Absolutamente desprecio a Agile. El método Waterfall tiene sus problemas, estoy de acuerdo, pero al final del día da como resultado características más completas, mejor código, mejores pruebas y una mejor base para el crecimiento.

He sido Scrum Master en dos compañías y he visto tanta estupidez en lo que respecta a la aplicación de Agile que estaba constantemente asqueado. Es importante tener en cuenta que ambas compañías estaban fallando miserablemente en el mercado con sus productos desarrollados por Agile de mala calidad. Utilizamos Jira para el seguimiento y clasificación de errores y características y constantemente priorizamos las características y la funcionalidad una y otra vez en función del acuerdo del día y, a veces, por estrategia. El resultado fue una interfaz de usuario imbécil con algunas características que incorporan GUI basada en la web, algunas usando texto basado línea por línea sin rima o razón de por qué algunas características eran bonitas y coloridas con apuntar y hacer clic y otras eran desplazarse y seleccionar. No importa cuánto intenté arreglar la IU, siempre había una característica o error más importante que necesitaba ser reparado o implementado. No pude soportarlo. Y debido a que corríamos en horarios de dos semanas, siempre fueron las pruebas las que sufrieron. Si las cosas se pusieron difíciles, solo probamos menos y esperamos lo mejor. Como resultado, siempre había llamadas de emergencia a medianoche con ingenieros en pánico a las tres de la mañana para arreglar a un cliente que estaba “en apuros”. La respuesta siempre fue “Lo arreglaremos en la próxima iteración”. Como resultado, el producto fue una pesadilla de soluciones y soluciones y parches temporales y parches en parches en parches.

Cuando estaba en Cisco, despreciaba el tren del código IOS: si perdías el tren, estabas jodido durante al menos un año, pero después de dejar Cisco y ver la absoluta estupidez de cómo trabajaba Agile en la práctica, me di cuenta de que la estrategia del tren de Cisco en realidad funcionó mejor a largo plazo. Sí, fue lento y torpe, pero sabía que las características y el código fueron probados y escritos con previsión. Todavía tuvimos problemas, pero nada como lo que vi en las ridículas comunidades ágiles donde trabajaba.

Gracias por el A2A.

Implementé Kanban con éxito en una empresa editorial, y fue un desafío ya que son bien conocidos por usar un proceso secuencial.

El flujo se basó en más de una sola junta debido a algunos departamentos que por varias razones (válidas) estaban trabajando de forma aislada o no podían colaborar de todos modos con otros grupos.

El trabajo atrasado podría ser fácilmente priorizado en caso de que surja alguna publicación urgente, varios miembros del equipo estaban trabajando en la misma tarjeta para evitar un montón de ida y vuelta que afectaba su proceso antes, el editor en jefe podía ver en cualquier tiempo el estado en el tablero, y una vez que se lanzó un grupo de tarjetas (un libro, una revista, un periódico) se entregó para su distribución (un tablero diferente).

El flujo inicial se ha mejorado o ajustado constantemente, pero ahora se aceita y se ejecuta.

Comercio electrónico, startup, equipo de 5-7 miembros, todos no técnicos, enfóquese en la interactividad, asegúrese de que se vea social e interactúe de manera uniforme, satisfaga a los interesados ​​y brinde transparencia y mitigación a la mesa