Scrum: ¿demasiado o no lo suficiente? [cerrado]

Question

Mi empresa ha comenzado recientemente a usar Scrum; Hemos hecho 2 sprints. Todavía estamos aprendiendo, pero definitivamente ya hemos expuesto y solucionado algunos problemas en nuestro proceso de desarrollo. Entonces, en general, creo que ha sido bueno para nosotros.

Al leer muchas de las reflexiones en Internet sobre Scrum de evangelistas, cínicos y todos los demás, se me han destacado tres temas comunes y un tanto contradictorios:

1. La implementación de Scrum falla porque los procesos de Scrum no se siguen lo suficientemente de cerca.
2. La implementación de Scrum falla porque la organización no adapta Scrum a su propio entorno / cultura / prácticas.
3. Los procesos de Scrum no son importantes; solo importan los valores en el manifiesto ágil.

Se pueden ver ejemplos de estos en las respuestas a estas preguntas de SO:

• ¿Ha tenido una mala experiencia con Scrum o Sprint?
• ¿Es Scrum malo?
• ¿Está muerto el desarrollo ágil?

Tengo que admitir que todavía no estamos siguiendo todas las pautas de Scrum: no hemos hecho una versión al final de los sprints, nuestro Scrum Master no quiere que eliminemos tareas de la cartera de sprint cerca del final del sprint para que pueda ver cuánto se perdió nuestra planificación (lo que significa que el gráfico de reducción de incendios nunca llega a 0), y los problemas urgentes de atención al cliente todavía tienen un poder increíble para interrumpir la planificación de todos, por algunos ejemplos.

Mi pregunta es: al tratar de resolver estos y otros problemas, ¿es mejor intentar estar más cerca de los procesos oficiales de Scrum, estar más cerca de algunos de nuestros procesos previos a Scrum? ¿O es mejor meditar sobre los principios de Scrum para intentar un proceso completamente diferente?

Answer 1

Yo diría que realmente te estás perdiendo uno de los componentes clave de la agilidad si no lo lanzas temprano y con frecuencia. En la medida en que no haga esto, su proceso no es ágil y está obligado a sufrir el mismo tipo de problemas que tienen los procesos tradicionales impulsados ??por el plan. Puede ser que esta sea una condición temporal, ya que solo te estás acostumbrando a las cosas, pero debes comenzar a lanzar en breve (y con regularidad).

Siempre tendrás problemas con los tapones, pero puedes ayudarlo acortando el sprint. Es posible que el cliente no pueda esperar un mes, pero puede esperar 2 semanas por algunas cosas. Por lo tanto, una duración más corta del sprint puede ayudarlo a diferir algunas solicitudes para el siguiente sprint, lo que las hará menos perturbadoras. También debe ser sincero con el cliente, ya que las interrupciones están causando que su ritmo sufra. Pueden elegir voluntariamente esperar si saben que algunas de las solicitudes retrasan sus funciones elegidas.

Otra observación que haría es que, como con casi cualquier cosa, es mejor comenzar siguiendo el patrón lo más cerca posible mientras aprendes. Una vez que tenga un buen conocimiento de los principios fundamentales, puede ver dónde se pueden doblar, romper o reemplazar algunos principios mucho más claramente para mejorar el proceso. Hasta que realmente lo entiendes, las cosas que cambias pueden doler o ayudarte; realmente no tienes idea, ya que no tienes la experiencia que te dice cómo deberían funcionar las cosas. A menos que su Scrum master tenga mucha experiencia, es posible que desee acercarse más a las prácticas definidas hasta que tenga algunos más sprints en su haber.

Answer 2

Casi todo lo que he leído en Scrum dice que una de las claves es adaptar el proceso para adaptarse a su propia situación. No hay dos equipos de desarrollo iguales, y diferentes cosas funcionan para diferentes personas.

Las ideas principales detrás de Scrum son:

Tenga un ciclo de retroalimentación ajustado de los requisitos al desarrollo y de vuelta a las partes interesadas.

Esto permite al equipo de desarrollo verificar continuamente que están construyendo algo que realmente se desea y permite que el desarrollo se ajuste fácilmente a medida que cambian los requisitos y las expectativas. Los interesados ??pueden agregar o eliminar funciones en cualquier momento y pueden ajustar la prioridad de las funciones a medida que cambien sus necesidades.

Mantenga el software en un estado en el que se pueda liberar al final de cualquier sprint dado.

Eso no quiere decir que haya lanzamientos cada sprint, sino que podría hacerlo si el cliente decide que quiere tener lo último. Esto también ayuda a un equipo de desarrollo a evitar la situación de infierno de integración que viene de las personas que salen y trabajan en una parte del proyecto durante meses a la vez, de manera aislada.

Sea completamente transparente con lo que está sucediendo en el desarrollo y todos deben estar dispuestos a hacer concesiones.

Aquí es donde la mayoría de los proyectos fallan y donde Scrum realmente puede tener éxito si todos participan en el proceso. Tantos proyectos de desarrollo se configuran donde una versión debe tener características X lanzadas en la fecha Y y no hay flexibilidad para cambiar eso. Esto se traduce en características a medio hacer y en un software cargado de errores, ya que los desarrolladores abarrotan para obtener todas las características requeridas en su lista de verificación.

La realidad es que suceden cosas inesperadas en el desarrollo de software. Con una comunicación abierta y participantes dispuestos en el proceso Scrum, los clientes y los desarrolladores pueden evaluar continuamente el estado actual del proyecto y tomar decisiones informadas sobre cómo priorizar el trabajo restante en el proyecto.

Answer 3

Scrum funciona . No con todos los equipos en todas las situaciones, pero se ha demostrado que funciona.

Le sugeriría intentar abarcar Scrum de libro de texto tanto como lo permita su entorno empresarial, ver cómo funciona, y luego afinarlo .

¿Por qué su maestro Scrum no quiere mover tareas fuera del registro de sprint? ¿No abraza al 100% los principios de Scrum? (Lo vería como preocupante en un Scrum master)

La mayoría de los problemas que implementan Scrum son en realidad solo problemas en el equipo o negocio que está siendo expuesto por el proceso Scrum, por ejemplo. - si sus sprints son rechazados por problemas de soporte imprevistos, esto sugiere que no está asignando suficientes recursos para apoyar

Answer 4

Cada empresa es diferente, cada proyecto es diferente y cada cliente es diferente.

Creo que es tan fácil fallar al seguir scrum (o cualquier otra metodología) muy de cerca en un entorno que no se ajusta a la metodología como fallar porque sigues scrum muy libremente en un proyecto que sí se ajusta.

Al final, algunas respuestas genéricas en un sitio de control de calidad no reemplazan el análisis serio de su propio proyecto, empresa, equipo y clientes. No existe una fórmula mágica y usted debe tomar su propia decisión.

Answer 5

Respuesta: debe adoptar Scrum y XP juntos para obtener todos los beneficios del scrum.

Razones :

Las razones se basan en años de experiencia con XP y scrum, y específicamente en lo que aprendí de la charla de Jeff Sutherland (para la ACCU en Londres, mayo de 2009)

• Scrum es una técnica de administración , no necesariamente un método de producción de software. Algunas personas usan scrum en otros dominios, p. Ej. preparando exposiciones en museos y gestionando instituciones religiosas ... para que tenga los mecanismos necesarios para que un equipo multidisciplinario realice el trabajo de manera adaptable en pequeños incrementos.
• Scrum, originalmente incluía todas las prácticas extremas de programación . Jeff Sutherland en realidad dijo que nunca ha visto a un proyecto de scrum lograr los mayores órdenes de productividad medidos para el scrum sin utilizar las prácticas de programación extremas.
• Scrum y XP vienen del mismo fondo : programación orientada a objetos, específicamente con Smalltalk. Los programadores se fueron y desarrollaron XP mientras que la gente de administración creó scrum. Necesita ambos aspectos: prácticas de desarrollo y prácticas de gestión.
• Las prácticas de XP se eliminaron deliberadamente de Scrum para facilitar su adopción. : implementar las prácticas de XP es difícil y es difícil que se adopten rápidamente. Jeff realmente dijo que Ken Schwaber eliminó las prácticas de XP para ayudar a las personas a comenzar con scrum. El peligro ahora es que este scrum mínimo se ha convertido en todo lo que la gente ve y espera.
• Muchos gerentes de proyectos no técnicos ahora enseñan scrum, pero no tienen el conjunto de habilidades para enseñar XP
• No todos los desarrolladores consideran que las prácticas de XP son fáciles de adoptar : pueden ser difíciles de vender y demoran unos meses en lugar de los 2 días que toma establecer un scrum básico.

Answer 6

Scrum no intenta solucionar los problemas técnicos en el desarrollo de software. Es solo un pequeño proceso de gestión.

• La fuerza del scrum es que no interfiere al prescribir muchos trabajos técnicos innecesarios o irrelevantes.
• La debilidad del scrum es que no te dice qué buenas prácticas técnicas debes hacer.

La programación extrema aborda los problemas técnicos involucrados en el desarrollo de software y encaja muy bien dentro del scrum. La razón por la que la gente del scrum no obligó a todos a hacer las prácticas técnicas de XP es que se necesitan unos 6 meses para implementar esas prácticas tecnológicas, en lugar de los 2 días que toma implementar el scrum más básico.

Si o no scrum es " mal " - Ciertamente hay inconvenientes con ello. Discutimos la difícil relación entre XP y Scrum en XP Days, Londres, 2009: http://xpday-london.editme.com/WhereHasXpGone

Answer 7

Scrum no es realmente el problema que estás mostrando. La mayoría de las metodologías de desarrollo funcionan, incluso la cascada, por mucho que nos guste golpearla, funciona. Scrum te hace concentrarte un poco más en las cosas importantes, pero no evitará que las personas tomen malas decisiones, como no seguir realmente el proceso.

El sistema es bastante simple en su núcleo.

Ver el problema. Definir lo que se hace es. Crea una serie de tareas que te permitan hacer. Estimar esas tareas. Seleccione suficientes para que pueda hacer algo en un corto período de tiempo. Completa las tareas. Enjuague y repita.

Es cierto que estos pasos están simplificados, y no he lanzado un scrum master y un cliente. Pero el punto es que el marco es solo una estrategia básica de administración del tiempo. Si las personas en su sistema son caóticas y no son buenas para hacer las cosas, el scrum realmente no las ayudará.

Answer 8

Es mejor comenzar a aplicar Scrum por el libro, y para entender realmente los principios y valores subyacentes de Manifiesto Agile , antes de personalizarlo, para que el proceso no se desnaturalice. Asegúrese de ejecutar retrospectivas al final de cada iteración (Sprint) para " inspeccionar y adaptar " su proceso y elimine el desperdicio .

Para tu Scrum Master, él puede rastrear lo que se elimina del Sprint actual. Además, los Sprints se planifican en función del logro de Sprints anterior, no de lo que se programó previamente. No entiendo su punto.