agile - que - Adopción ágil(Scrum): ¿cómo te fue?

que significa scrum (8)

Hacemos la mayoría de los proyectos de scrum en el sitio del cliente. La parte más difícil de mi experiencia es encontrar un buen propietario de un producto en la organización del cliente:

Demasiadas personas piensan que deberían ser el dueño del producto,
El propietario del producto tiene dificultades para seguir el ritmo del equipo
El propietario del producto tiene dificultades para obtener toda la información detallada que el equipo necesita
Mover elementos en la cartera de pedidos del producto para agregar algo con una prioridad más alta es difícil
etc.

Capacitar a los equipos internos para que usen scrums es factible, ya que es posible implementar su propio scrum master, pero un buen propietario del producto debe ser parte de la organización del cliente. Es más difícil entrenar a esta persona externa. Tener un propietario de producto proxy, que trabaje junto con el propietario del producto del cliente ayuda mucho.

Para aquellos de ustedes que han implementado Scrum en sus organizaciones, ¿cuáles fueron sus mayores obstáculos y si los superaron, cómo?

Antecedentes : en 2006, contraté a una gran compañía que había adoptado Scrum cold turkey unos meses antes de mi llegada. La compañía esperaba que Agile / Scrum salvaría su enorme producto de software empresarial. De los cien o más programadores allí, trabajé en estrecha colaboración con un equipo de alrededor de una docena durante un año, observando y participando en su experimento Agile.

Resumen : creo que Agile ayudó más de lo que dolió. Antes de fin de año, el equipo podría estimar y producir consistentemente características, mientras que antes su productividad era bastante errática.

Implementación : Dado que se trataba de una gran organización y un gran producto, el proyecto funcionó como un "scrum de scrums". Hubo un maestro de scrum para aproximadamente cada 15-20 desarrolladores y estos equipos a menudo se dividieron en scrums más pequeños, de cerca de 6-8 personas para una iteración. Los equipos eran en gran parte independientes, podían ajustar su propia frecuencia de iteración (1 mes a 1 semana) y se les dio mucha flexibilidad para implementar ágil como mejor les pareciera. La compañía regularmente trajo entrenadores Agile (como Object Mentor) para ayudar a entrenar a los maestros de scrum, equipos y administración.

Obstáculos : Mucho. Algunos de ellos relacionados con Agile, otros no. Sin un orden en particular, aquí hay algunas lecciones aprendidas:

La cartera de pedidos del producto se revisó con demasiada frecuencia al principio. Eventualmente, el equipo y la administración tardaron varios días en revisar todas las características, estimarlas y priorizarlas. Fue un gran éxito, pero ayudó enormemente. Lección aprendida: consiga el retraso acumulado de su producto en orden temprano y manténgalo actualizado. Los propietarios del producto deben tener una idea clara de lo que quieren.

Perdimos el tiempo experimentando y lidiando con modas y exageraciones. Cuando comienzas, no tienes forma de saber si estás haciendo las cosas correctamente. Existe la tentación de jugar constantemente con el proceso ágil alejando el enfoque del producto. Lección aprendida: tener un coach Agile experimentado ayuda a reducir esta curva de aprendizaje. Siempre debe haber alguien reprimiendo cualquier experimentación. Limite el número de "picos".

Un buen maestro de scrum es invaluable. Ciertamente al principio, es una posición de tiempo completo.

Toma tiempo. Pasaron varios meses antes de que el equipo comenzara a sentirse cómodo con el proceso.

Escoge tus batallas. Algunos programadores serán comprensiblemente escépticos y otros sentirán disgusto absoluto y aceptarán el cambio. Permita algo de flexibilidad. Por ejemplo, imponer el uso de una acumulación de productos y un calendario de iteraciones, pero no es necesario que todos usen tarjetas de notas. Sea particularmente sensible a la introducción de herramientas y metodologías de programación, como la programación de pares o el primer desarrollo de prueba.

Finalmente, mantenga la comunicación abierta y gestione las expectativas.

¡Buena suerte!

El mayor problema, como ya se dijo, que yo también he experimentado es la falta de aceptación. Es muy difícil conseguir que la gente se convierta verdaderamente en el proceso.

El otro problema, que también contribuye directamente a la cuestión anterior, y también en gran parte a una de las causas fundacionales de Agile, es la falta de gestión para seguir los lineamientos del manifiesto de Agile.

En Scrum, Lean, o cualquier versión de Agile con la que estés trabajando, no se puede romper con los puntos del manifiesto. Si se utiliza un proceso para romper con esas prioridades, lo más probable es que la administración se arruine y la compra se desmorone. El manifiesto DEBE ser seguido:

Manifiesto:

Individuos e interacciones sobre procesos y herramientas
Software de trabajo sobre documentación completa
Colaboración del cliente sobre la negociación del contrato
Responde al cambio sobre el siguiente plan

Algunos escenarios pueden ser cuando aparece un diagrama de Gantt de uno de los procesos anteriores por cualquier razón. Los diagramas de Gantt pueden ser útiles, pero si de repente un desarrollador está revisando un diagrama de Gantt con la administración, el último punto se rompe. La respuesta al cambio se ha desacelerado porque se está favoreciendo el estímulo del plan frente al cambio. En su lugar, se debe usar una tabla con elementos adhesivos, simplifique lo que está en el tablero con solo los elementos de trabajo actuales y los elementos de la parte posterior del quemador. Esto hace que los cambios sean fáciles. Una vez que todo se solidifica en una "herramienta", se ralentiza la respuesta a los cambios. Claro, la administración necesita registrar y rastrear cosas de alguna manera, pero empujar eso hacia el desarrollo solo ralentiza la respuesta al cambio, y empujar herramientas a los desarrolladores (a menos que los quieran para el desarrollo y puedan utilizarlos apropiadamente) arruina el primer punto, de los individuos sobre las herramientas y el proceso.

De otra manera, no detenga el desarrollo con el fin de escribir documentación completa. A menos que solo tenga un único desarrollador, entonces alguien debería tomar la carga de la documentación de forma autónoma desde el rol de desarrollo. Presionar estas cosas juntas ralentiza drásticamente el desarrollo y, durante períodos de tiempo, puede cerrar cualquier esfuerzo para obtener realmente un software en funcionamiento.

El último punto es SIEMPRE mantenerse en contacto de alguna manera con el cliente o posible cliente. Háblales regularmente sobre lo que quieren. Hable con ellos a diario y muéstreles todo lo que pueda de UI, o incluso flujo de datos. Cualquier cosa que ellos entiendan que deberían ver. Hable con ellos, infórmeles sobre la arquitectura y las ideas que se incluyen en la aplicación y nunca olvide que está creando la aplicación para ellos.

Resumen:

El mayor problema es comprar. Segundo, la administración se apega a las pautas del manifiesto.

Si puedes mitigar estos dos riesgos, deberías ir. Todo lo demás es divertido después de obtener la aceptación y lograr que la gerencia entienda que tendrán que ser realmente fuertes y gerentes de administración no micro. Específicamente, los gerentes pueden incluso necesitar convertirse en clientes potenciales, o llenar un estilo diferente de rol.

... espero no haberme desviado demasiado del tema. :)

Me mudé de una empresa que adoptó Agile hasta el tee a otra compañía que sigue las metodologías tradicionales.

Quizás la mayor diferencia que he visto es que a la segunda empresa le cuesta priorizar. Hay tanto trabajo en el plato de cada persona que no entregan a tiempo. IMO, Agile aporta cierta transparencia a la situación y permite que el equipo en su conjunto priorice.

Un maestro del scrum en el mundo Ágil se encargaría de la lucha contra incendios y sería la voz del equipo (sprint). De hecho, en la primera compañía (donde teníamos un maestro de scrum y un gerente de programa), el maestro de scrum luchaba con el gerente de programa cuando este último hacía falsas promesas a la gerencia. Es decir, el maestro del scrum sabe cuánto puede producir / entregar un equipo después de algunos sprints, lo que le ayuda a determinar la previsibilidad de un equipo.

También noté que los recursos de I + D tienen una sensación de logro al final de cada ciclo y esperan con ansias el siguiente. Pero luego, un buen gerente de proyecto podría hacer esto en escenarios tradicionales también.

He estado ejecutando Scrum en varios proyectos. El mayor problema, según lo veo, es que no todos en la organización están en el proceso. Todos deben estar comprometidos. No solo el equipo de desarrolladores. A menudo, los gerentes son las personas que inician el proceso y esperan que las cosas cambien para mejor sin que ellos hagan nada.

Mi sugerencia es que organices un taller con toda la organización para que todos sepan cómo funciona el proceso. No solo los desarrolladores Es esencial que tengas una persona que esté realmente interesada en el proceso. Una persona que puede responder preguntas que el equipo y la organización tienen. Un mentor.

Ser ágil se trata de dar la bienvenida al cambio. No debe permitir que el proceso se interponga en el sentido. Haga las cosas que funcionan para su organización, pero debe probar todo el proceso antes de tirar algo.

Mientras trabajaba como desarrollador de Delphi hace unos años, logré que Scrum fuera adoptado por mi equipo de desarrollo por un tiempo.

Todo el proceso funcionó muy bien para nosotros: hacer que el equipo calcule las tareas priorizadas en un retraso acumulado nos dio plazos significativos para orientarnos, y todo el "trabajo de Gestión es para eliminar impedimentos" fue excelente.

El mayor problema fue que el proceso siempre se percibió, y se lo mencionó, como "la buena idea de Bevan".

Si bien el equipo apreció el valor que obtuvimos y nos complació continuar con Scrum, el Equipo no tomó la metodología de scrum como suya . Después de un tiempo, me cansé de "empujar" y nos "caímos" de seguir el enfoque de Scrum.

Lección: Asegúrate de que el equipo toma a Scrum a bordo y es el propietario del enfoque.

Implementamos Agile (conjunto de SCRUM - gestión y XP - práctica de ingeniería) en un entorno que era cascada con grandes proyectos en un entorno que estaba muy integrado. La cascada de la policía estaba en todas partes. Como se puede imaginar, muchos proyectos fallaron. Después de haber hecho Agile en un empleador anterior, recibimos permiso para probar ágil para el proyecto.

Internamente para el equipo, utilizamos la práctica Ágil. Externamente, completamos las prácticas ágiles con procesos de cascada que significan principalmente informes. Por lo tanto, miramos desde el exterior como un proyecto de cascada. Sin embargo, había una gran diferencia, internamente estábamos usando Agile y consecuentemente entregábamos, a tiempo, dentro del presupuesto con alta calidad.

Los factores críticos de éxito fueron los entrenadores integrados (Coach de Iteration Manager, Dev Lead Coach, Test Lead Coach y Solution Analyst Coach). Asegurar el compromiso del sistema dependiente por adelantado (se requiere que miremos hacia adelante para identificar los sistemas dependientes y el trabajo requerido de esos sistemas) era una necesidad en un entorno fuertemente integrado. Antes de comenzar, sumergimos a los miembros técnicos y empresariales del equipo en un campo de entrenamiento ágil. Esto aseguró que los jugadores clave (el dueño del producto y el equipo técnico) conocieran sus roles y pudieran ejecutarlos de manera efectiva. Finalmente, el ajuste del proyecto con los informes de cascada nos permitió vincularnos con toda la estructura de informes existente en la empresa.

El resultado neto es que la compañía ahora está moviendo los proyectos de cascada a ágiles. Todo esto es posible solo porque hemos podido ofrecer software de alta calidad a un ritmo sostenible.

Donde trabajo ha estado usando Scrum por un tiempo, pero parece haber pasado por algunas fases. En términos de obstáculos, una parte es evitar introducir demasiados cambios a la vez y simplemente presentar las cosas lentamente, por ejemplo, poner en pie una presentación diaria una semana, un par de semanas poner una historia, un par de semanas más tarde traer la programación de los pares . Esto permite que los diversos ajustes funcionen y si los cambios mejoran las cosas, esto puede ayudar a generar un buen impulso. Otro punto es asegurarse de que si hay cambios en la forma en que se hace algo, no se menosprecie ni se burle de la persona que se está corrigiendo. A veces esto puede significar que interrumpes a alguien o que traes un "¿Podemos volver a lo básico?" o algo similar para tratar de poner las cosas en orden en lugar de simplemente gritarle a alguien o hacer algo que sea contraproducente.

Traer a los consultores fue una de las mejores cosas que se hicieron aquí, IMO. Ahora, estos muchachos vinieron para ayudar a evolucionar cómo se hizo el desarrollo aquí. Traer en programación de pares, TDD, conceptos como ventanas rotas, organizar carpetas de proyectos y traer burlas para las pruebas, fueron todas excelentes adiciones que, aunque pudimos haber llegado allí por nuestra cuenta, puede haber llevado mucho tiempo que no funcionaría. tan bien