project management - metodologia - Scrum: ¿demasiado o no es suficiente?

product owner (8)

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

Creo que es tan fácil fallar siguiendo muy de cerca el scrum (o cualquier otra metodología) en un entorno que no se ajusta a la metodología, ya que es un error porque sigues el scrum demasiado libremente en un proyecto que encaja.

Al final, una respuesta genérica en un sitio de QA no reemplaza al análisis serio de su propio proyecto, compañía, equipo y clientes: no existe una fórmula mágica y usted debe tomar su propia decisión.

Mi compañía recientemente comenzó 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 los evangelistas, cínicos y todos los que están en el medio, tres temas comunes y algo contradictorios me han destacado:

La implementación de Scrum falla porque los procesos de Scrum no se siguen con la suficiente atención.
La implementación de Scrum falla porque la organización no adapta Scrum a su propio entorno / cultura / prácticas.
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 SO:

Tengo que admitir que todavía no estamos siguiendo todas las pautas de Scrum: no hemos hecho un lanzamiento al final de los sprints, nuestro Scrum Master no quiere que retiremos las tareas del backlog de sprints cerca del final. del sprint para que pueda ver cuánto se redujo nuestra planificación (lo que significa que el gráfico burndown nunca pasa a 0), y los problemas urgentes de soporte al cliente aún 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 tratar de estar más cerca de los procesos oficiales de Scrum, estar más cerca de algunos de nuestros procesos anteriores a Scrum, o mejor para meditar en los principios de Scrum para intente y proponga un proceso diferente por completo?

Casi todo lo que he leído en Scrum dice que una de las claves es adaptar el proceso a tu 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 estricto desde los requisitos hasta el desarrollo y de vuelta a los interesados.

Esto permite que el equipo de desarrollo verifique continuamente que están creando algo que realmente se quiere y permite que el desarrollo se ajuste fácilmente a medida que cambian los requisitos y las expectativas. Las partes interesadas pueden agregar o eliminar funciones en cualquier punto y pueden ajustar la prioridad de las funciones a medida que cambian sus necesidades.

Mantenga el software en un estado en el que sea liberable al final de cualquier sprint dado.

Eso no quiere decir que tengas lanzamientos cada sprint, pero podrías 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 la integración que proviene de que las personas se desconecten y trabajen en una parte del proyecto durante meses en forma 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 fracasan y donde Scrum realmente puede tener éxito si todos se incorporan al proceso. Se han configurado tantos proyectos de desarrollo para los que una versión debe tener características X lanzadas en la fecha Y y no hay flexibilidad para cambiar eso. Esto da como resultado funciones a medio hacer y software basado en errores a medida que los desarrolladores se preparan para obtener todas las características requeridas en su lista de verificación.

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

Diría que realmente te falta uno de los componentes clave de la agilidad si no lo haces temprano y con frecuencia. En la medida en que no lo haga, su proceso no es ágil y está sujeto a sufrir los mismos tipos de problemas que los procesos tradicionales basados en planes. Puede ser que esta sea una condición temporal, ya que te estás acostumbrando a las cosas, pero necesitas comenzar a liberar pronto (y regularmente).

Siempre tendrás el problema con los bloqueadores del show, pero es posible que puedas ayudar al acortar la duración del sprint. Es posible que el cliente no pueda esperar un mes, pero es posible que pueda esperar 2 semanas para algunas cosas. Una longitud de sprint más corta, entonces, puede ayudarte a diferir algunas solicitudes para el siguiente sprint, lo que las hace menos disruptivas. También debe ser sincero con el cliente en cuanto a que las interrupciones están causando que su ritmo sufra. Pueden elegir voluntariamente esperar si saben que algunas de las solicitudes están retrasando las características que eligieron.

Otra observación que haré es que, como con casi cualquier cosa, es mejor comenzar siguiendo el patrón lo más cerca posible mientras aprendes. Una vez que tiene una buena comprensión de los principios fundamentales, puede ver dónde algunos principios se pueden doblar, romper o reemplazar mucho más claramente para mejorar el proceso. Hasta que realmente lo obtengas, las cosas que cambias pueden herir o ayudar, realmente no tienes idea ya que no tienes la experiencia que te dice cómo deberían funcionar las cosas. A menos que tu maestro de Scrum sea realmente experimentado, tal vez quieras acercarte más a las prácticas definidas hasta que tengas algunos sprints más bajo tu cinturón.

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

Sugiero tratar de adoptar el libro de texto Scrum tanto como lo permita su entorno empresarial, ver cómo funciona y luego ajustarlo .

¿Por qué su maestro Scrum no quiere mover las tareas fuera de la acumulación de sprints? ¿Él no abraza al 100% los principios de Scrum? (Vería eso como algo preocupante en un maestro de Scrum)

La mayoría de los problemas al implementar Scrum son, en realidad, problemas en el equipo o negocio expuestos por el proceso de Scrum; por ejemplo, si tus sprints son eliminados por problemas imprevistos de soporte, esto sugiere que no estás asignando suficientes recursos para soportar

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

El sistema es bastante simple en su núcleo.

Vea el problema. Definir qué es hecho. Cree una serie de tareas que lo harán funcionar. Estime esas tareas. Seleccione suficientes para que pueda hacer algo en un corto período de tiempo. Completa las tareas. Enjuague y repita.

De acuerdo, es cierto que estos pasos se simplifican y no he incluido un maestro de scrum 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, entonces scrum realmente no las ayudará.

Es mejor comenzar a aplicar Scrum según el libro y comprender realmente los principios y valores subyacentes del manifiesto Ágil , 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 eliminar el desperdicio .

Para su Scrum Master, puede rastrear lo que se elimina del Sprint actual. También Sprints se planifican en base al logro Sprints anterior, no en lo que se programó previamente. No entiendo su punto.

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

Razones:

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

Scrum es una técnica de gestión , no necesariamente un método de producción de software. Algunas personas usan el scrum en otros dominios, por ejemplo, preparando exposiciones de museos y administrando instituciones religiosas ... por lo que tiene los mecanismos que necesita para que un equipo multidisciplinario entregue el trabajo de manera adaptable en pequeños incrementos.
Scrum, originalmente incluía todas las prácticas de programación extrema . Jeff Sutherland en realidad dijo que nunca había visto un proyecto de scrum lograr los pedidos más altos de productividad medidos para scrum sin utilizar las prácticas de programación extremas.
Scrum y XP provienen del mismo fondo : programación orientada a objetos, específicamente con Smalltalk. Los programadores salieron y desarrollaron XP mientras que los gerentes crearon 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 lograr que se adopten rápidamente. Jeff dijo que Ken Schwaber eliminó las prácticas de XP para ayudar a las personas a comenzar a usar el scrum. El peligro ahora es que este melé mínimo se haya convertido en todo lo que las personas ven y esperan.
Muchos gerentes de proyectos no técnicos ahora enseñan scrum, pero no tienen las habilidades para enseñar XP
No todos los desarrolladores encuentran que las prácticas de XP son fáciles de adoptar : pueden ser difíciles de vender y lleva unos pocos meses en lugar de los 2 días necesarios para establecer el scrum básico.

Scrum no intenta abordar 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 obstaculiza la prescripción de muchos trabajos técnicos innecesarios o irrelevantes.
La debilidad del scrum es que no te dice qué buenas prácticas técnicas hacer.

La Programación Extrema aborda los problemas técnicos involucrados en el desarrollo de software y se adapta muy bien dentro del scrum. La razón por la cual la gente del scrum no forzó a todos a hacer las prácticas técnicas de XP es que lleva aproximadamente 6 meses implementar esas prácticas tecnológicas, en lugar de los 2 días que lleva implementar el scrum más básico.

Ya sea que el scrum sea o no "malvado", sin duda hay inconvenientes en él. Hablamos de la relación incómoda entre XP y Scrum en XP Days, Londres, 2009: http://xpday-london.editme.com/WhereHasXpGone