¿Por qué necesito SCRUM frente a un proceso menos formal y más ligero para mi equipo?

Me gustaría comenzar mi pregunta diciendo que entiendo que SCRUM o algún derivado de él probablemente sea una buena manera de administrar el desarrollo de software. Parece que todas las grandes empresas y mis gerentes lo usan o lo han usado, y realmente no puedo discutir con toda esa experiencia. Sin embargo, estoy luchando por entender los "porqués" y toda la lectura e incluso mi entrenamiento oficial SCRUM en el trabajo no está haciendo el trabajo por mí. Es solo retórica. Entonces vengo aquí buscando respuestas.

Hasta ahora, me he desarrollado en equipos de 4-5 miembros de manera muy efectiva, completamente autoorganizada y sin la necesidad de capacitación, metodología o software especial. Solo debates en cubos, reuniones ad hoc y revisiones de código uno a uno. Ahora estoy en una posición en el trabajo donde nos dicen que SCRUM es el camino a seguir, y todo lo que conlleva. Cuando me describen SCRUM, leo cosas como esta:

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

Eso es genial, pero todo me parece sentido común. ¿Por qué esta necesidad codificada? Entonces me dicen que la metodología nos ayuda a responder al cambio. Que especifico¿Los aspectos de SCRUM me permiten ser tan flexible que no estaba logrando previamente con mis reuniones ad hoc, discusiones de cubos y reuniones de planificación de desarrolladores? Explican la necesidad de tener una entrega de trabajo cada dos semanas, o sprint. En mi proyecto en particular, no hay un "cliente", el software no estará terminado por un año o más, y mientras tanto probablemente solo esté haciendo demostraciones a la alta gerencia cada mes o menos. Entonces, ¿por qué la necesidad explícita de una entrega cada dos semanas? Enfatizan la importancia de la reunión de planificación del sprint donde todo el equipo presenta las historias y las tareas para el próximo sprint. Esto no es diferente a las reuniones de planificación improvisadas que he tenido en el pasado. ¿Por qué debe ocurrir cada dos lunes, ¿Y por qué tiene que participar todo el equipo? Entiendo el concepto de que cada miembro "sea el propietario" del producto, pero el hecho es que solo unas pocas personas realmente pueden contribuir a dividir cada historia en tareas, mientras que el resto solo observa distraídamente.

Una vez más, entiendo que la mayoría de las personas están detrás de este proceso, por lo que debe funcionar y necesito participar. Solo me gustaría entender por qué. ¿Mi problema es que ya practico estas cosas y simplemente no me gusta codificarlas innecesariamente? ¿O tal vez todavía no he visto las ventajas de estas técnicas porque se están haciendo de manera incorrecta? Cualquier información real , personal o consejo sobre esto, a diferencia del anuncio que estoy acostumbrado a recibir, sería muy apreciada.

Creo que hay dos aspectos para responder a su pregunta, pero permítame comenzar felicitándolo por trabajar con personas que parecen ser lo suficientemente inteligentes y competentes como para poder trabajar prácticamente sin un proceso bien definido y aún así entregar un producto. Desafortunadamente, este no es un caso en todos los equipos de software, por lo que tal vez uno de sus problemas con Scrum podría ser que usted y sus compañeros de trabajo en realidad no necesitan que se les aplique un proceso para que sean más efectivos. Puede que ya seas efectivo.

Otros equipos no lo son y necesitan un proceso más estrictamente definido y algunas pautas para lograr que hagan las cosas. Esto no significa que estos equipos sean más estúpidos o menos capaces, solo significa que tal vez tengan problemas para autoorganizarse o trabajar con disciplina como equipo. Esto también puede ser una experiencia de aprendizaje simple cuando viene de un lugar donde la gente trabaja principalmente sola para trabajar en equipo. Scrum puede ayudar a llegar allí, ya que ofrece algunas pautas que son lo suficientemente fáciles de entender y seguir, pero lo suficientemente efectivas como para presionar al equipo para que comience a organizarse.

Dado que Scrum no dice nada sobre la forma en que se debe hacer el desarrollo de software, también deja al equipo con la libertad de decidir por sí mismos (por ejemplo, todavía puede hacer un sprint aplicando un método de cascada bastante conservador siempre que haya terminado en el final del sprint).

Entonces el equipo es un problema. El otro problema es la gestión y la confianza en la gestión. Aquí, Scrum podría ser bueno porque es transparente y permite a cualquier parte interesada ver el progreso que hace el equipo en ciclos definidos. Entonces no es "estamos progresando, desafortunadamente no podemos mostrarle nada en este momento, pero créanos, terminaremos a tiempo". Esto puede ser incluso cierto, pero puede ser tranquilizador para cualquier gerente tener una demostración regular en la que puedan ver que el progreso realmente ha sucedido.

Scrum no es una bala de plata. Puede que no funcione para algunos equipos por una variedad de razones, tal vez para algunos equipos la autoorganización no funciona. Quizás para ti sea al revés y parezca un proceso volcado en un equipo ya productivo y organizado.

En caso de duda, te sugiero que lo pruebes y lo veas. Si no funciona y a la mayor parte del equipo no le gusta trabajar de esa manera, no lo haga. Sin embargo, échale un vistazo por un par de meses (digo un par de meses, porque los primeros sprints serán incómodos de todos modos y necesitas tiempo para ajustar los detalles) y luego vuelve a evaluar.

Puede ser controvertido, pero Scrum es mejor para disminuir los temores de gestión de Agile, o para usarlo con un equipo que ya no rinde. Si su equipo funciona de maravilla, cumple objetivos, gana dinero y es feliz, Scrum no le comprará nada porque lo único que hará es alterar el buen equilibrio de las actividades que realiza (y hacer que su equipo tenga éxito). Scrum no es una bala de plata. En mi experiencia con él, solo ayuda a los equipos que tenían una mala estimación y comunicación para empezar. Un equipo que trabaja con estimaciones realistas en un entorno de comunicación efectiva solo se ve obstaculizado por la sobrecarga del proceso de Scrum.

Lo creas o no, existían buenos equipos de software antes de que apareciera Scrum. Scrum ayuda a los malos a mejorar.

La mayoría de las respuestas aquí ya han enumerado la razón, aunque un poco indirecta. La respuesta de Anne es especialmente esclarecedora cuando toca la transparencia. Es decir, permitir a los gerentes ver lo que está sucediendo. Y la respuesta de Schultz también toca esto cuando habla de que las personas no pueden ocultar el hecho de que están aflojando.

Entonces, me gustaría decir lo que otros ya están diciendo, pero en un lenguaje más directo: el objetivo principal de SCRUM no es administrar el desarrollo de software, el objetivo principal de SCRUM es medir el desarrollo de software.

Otros sistemas lo han intentado antes y las personas han propuesto innumerables métricas para intentar medir el desarrollo de software, pero han fallado. SCRUM le da la vuelta al problema y desvía la carga de la medición de los gerentes a los propios desarrolladores. La lógica es simple: ¿quién mejor para estimar cuánto tiempo lleva hacer algo que quienes hacen el trabajo ellos mismos?

Ahora, el problema con esto es que los programadores son bien conocidos por ser demasiado optimistas. Pregúntele a un programador cuánto tiempo lleva hacer algo y, por lo general, subestimará la dificultad de la tarea. SCRUM proporciona las herramientas para controlar esto:

• Reuniones diarias para evaluar el progreso y obtener una visión general del proyecto.
• las estimaciones se realizan en "puntos" en lugar de horas / días para abstraer el tiempo
• gráficos de quemado y gráficos de tortuga / liebre para visualizar la velocidad de los puntos
• historias y tareas en un tablero para obtener una visión general de la carga de trabajo
• sprints e iteraciones para actuar como fechas límite para que podamos medir el progreso
• roles específicos para scrum master, propietario y miembro del equipo para evitar la tentación de hacer trampa

etc.

Puede notar que todo lo anterior hace principalmente dos cosas:

1. Miden el trabajo. O trabajo por hacer o trabajo por hacer o trabajo completado.
2. Se esfuerzan mucho por evitar el problema del programador demasiado optimista para obtener una estimación mejor y más realista.

Cuanto más tiempo implemente SCRUM, más precisa será su estimación. De hecho, personalmente creo que ejecutar sprints + un trabajo pendiente + un cuadro de quemado solo es suficiente para curar a la mayoría de los programadores de hacer malas estimaciones sobre cuánto tiempo lleva hacer algo.

Personalmente, creo que el propósito de SCRUM es satisfacer a las organizaciones más antiguas donde la alta gerencia no puede o no va a respaldar un proceso más ágil. He estado trabajando como arquitecto (Chicken) durante aproximadamente un año en un departamento que utiliza mucho SCRUM. Mis antecedentes anteriores son las nuevas empresas de Silicon Valley, la mayoría de las cuales utilizaban un proceso centrado en funciones mucho más ágil, ad hoc y altamente iterativo (a veces semanal o incluso diario). Creo que SCRUM, al menos la forma en que lo implementamos, es excesivo en términos de proceso (y de alguna manera más pesado que la cascada (al menos desde la perspectiva del desarrollador). Para ser más justo, diré que un aspecto de nuestro proceso que se desvía es que nuestros propietarios de productos son más parecidos a los analistas de requisitos de la organización de TI. Como resultado, tienden a opacar la información proveniente del negocio y, lo que es peor, dejan al negocio sin rendir cuentas al equipo de desarrollo (que requiere infusiones sucesivas regulares de historias de usuarios). Sin embargo, en mi futuro inicio, no usaría un SCRUM. Probablemente solo lo usaría en la situación en la que la administración requiere la sobrecarga adicional.

No hablaré desde la perspectiva de un purista. Siento que puedes ejecutarlo de manera similar a lo que dice Scrum. Sin embargo, el punto principal es su capacidad para ejecutar el programa. ¿Qué pasará si estás de vacaciones por un mes?

Veo scrum como mecanismo para simplificar todo lo que has estado haciendo y poner algunos aspectos definidos sobre eso. Para que, en su ausencia, alguien más también pueda replicarlo y también puede replicarlo en otros proyectos. Sin embargo, el scrum no es una bala de plata. He visto a muchas personas que acaban de comenzar a usar Scrum (porque está de moda) y fueron maltratadas porque no entendieron la esencia de esto.

PD: Scrum no exige que tu sprint tenga una duración de dos semanas. Puede durar un mes (su caso).

Por favor, vea mis comentarios a la pregunta primero.

SCRUM es un paradigma de desarrollo de software ágil. Como tal, es ágil en sí mismo. No asume que debes seguir su modelo clásico. Y dudo si alguien lo hace en realidad. Solía ​​trabajar en varias organizaciones y cada equipo lo adaptaba a sus necesidades. No es inusual que no haya un cliente / consumidor cuando se trata de lanzar algún producto público / biblioteca / API. Nunca tuve uno. En mi caso, nuestro GM actuó como uno, lo cual fue como si no tuviera ninguno.

Tener 2 semanas de sprints es difícil. Muy rudo. 3 semanas es mejor, pero es realmente para el equipo de proceso experimentado y familiarizado. Teníamos 4 semanas o un mes. Eso nos dio tiempo suficiente para "conformarnos", por así decirlo, al principio y tener más confianza al final debido a más pruebas. Me gustó y me quedaría con al menos 3 semanas.

El otro equipo con el que estaba colaborando no tenía más que trabajo atrasado. Se reunirían, informarían sobre el estado y lo que sigue y eso es todo. Una vez que todo estuviera hecho, se les ocurriría otro retraso. Sabían que no era SCRUM, pero les funcionó y eso es lo importante.

¿Es más liviano? Definitivamente lo es. Pero no es SCRUM. Lo que me gusta de SCRUM es que promueve la disciplina. La gente siente la presión de entregar algo todos los días. Todos saben lo que hacen los demás y él falla, todos lo sabrán. Incluso si uno trata de ocultar eso (leer mentira), se hace evidente mucho antes que con otros procesos. Entonces, cuando diverges y simplificas como con ese equipo, debes asegurarte de hacerlo con las personas adecuadas. De lo contrario, puede desmoronarse muy rápidamente y degradarse a reuniones de estado sin sentido donde todos se quedarían y pensarían "¿qué hago aquí? Sé lo que tengo que hacer, ¿qué demonios?"

Esos son mis dos centavos. Hago mi propio SCRUM como desarrollo: planificar el trabajo, dividirme en tareas, estimarlas, observar el progreso. Realmente me ayuda a estar al tanto de las cosas. Apliqué algunas cosas de SCRUM a proyectos que subcontraté y funcionó muy bien para mí.

Solo ... mantente ágil ;-)

Te recomiendo que ignores el scrum. En un par de años aparecerá una nueva moda, y usted será menos cínico y aún podrá abrazarlo de todo corazón. De hecho, podría convertirse rápidamente en un experto. Entonces puede ganar mucho dinero escribiendo un libro sobre él y hablando en conferencias.

Dado que muchas cosas son cíclicas, lo más probable es que esta nueva moda sea un proceso pesado similar al RUP. Lo que habrá sucedido es que todos habrán seguido procesos ágiles y livianos, y estos serán culpados por los fracasos de sus proyectos. Entonces, por supuesto, la solución lógica es que se requiere más planificación y diseño por adelantado.

En serio, no creo que necesites Scrum. No hay nada en scrum que sea mejor que otros procesos ágiles competidores. También tiene muchos nombres estúpidos para las cosas.

Eso es genial, pero todo me parece sentido común. ¿Por qué esta necesidad codificada?

Scrum generalmente se compara con metodologías más antiguas y más pesadas. Las metodologías intentaron hacer que la cascada sin comentarios funcionara aplicando más documentos, más cierre de sesión y más planificación por adelantado. El manifiesto ágil (que estás citando) fue una inversión de esas ideas.

Entonces me dicen que la metodología nos ayuda a responder al cambio. ¿Qué aspectos específicos de SCRUM me permiten ser tan flexible que no estaba logrando previamente con mis reuniones ad hoc, discusiones de cubos y reuniones de planificación de desarrolladores?

Parece que ya tienes una estructura ágil. Si ya está respondiendo bien al cambio, entonces obviamente no necesita ayuda. Algunos procesos se vuelven tan ocultos con el procedimiento que corregir un error requiere un análisis completo y una fase de diseño funcional, y no puede ingresar al proyecto hasta el próximo año, como muy pronto.

Explican la necesidad de tener una entrega de trabajo cada dos semanas, o sprint. En mi proyecto en particular, no hay un "cliente", el software no estará terminado por un año o más y, mientras tanto, es probable que solo esté haciendo demostraciones a la gerencia superior cada mes o menos. Entonces, ¿por qué la necesidad explícita de una entrega cada dos semanas?

Scrum original prescribe sprints de un mes. Hay una tendencia desagradable hacia el machismo ágil en los sprints de acortamiento. ("Sí, bueno, nuestros sprints duran solo un día ...") El Cliente / Cliente es quien tiene la autoridad para decir que el proyecto está listo o necesita más trabajo. Si está haciendo una demostración a la administración superior todos los meses, probablemente sean su cliente, y probablemente ya esté muy cerca de Scrum.

Según su descripción de lo que está haciendo su equipo, Scrum probablemente no sea muy diferente. Puede obtener algún valor de la estandarización, porque será más fácil explicar a los extraños lo que está sucediendo si usa los términos Scrum. Además, Scrum se puede usar como escudo; por ejemplo, Scrum prescribe que las decisiones técnicas deben ser tomadas por el equipo; señalar este principio puede ser una buena manera de obtener un valor técnico que de otro modo sería difícil de vender (programación de pares, por ejemplo).

Scrum es básicamente una interfaz que su equipo puede implementar. Si lo hace, entonces tiene una buena idea sobre cómo comunicarse con los que están fuera del equipo, y ellos tienen una buena idea sobre cómo comunicarse con usted. Solo tú puedes saber si tu equipo necesita esto.

No usamos Scrum en el trabajo. Utilizamos una metodología fundada en Agile and Lean que es similar en muchos aspectos. He usado este proceso en equipos que varían en tamaño entre 3-5 personas, incluido el líder. Aunque existen diferencias, creo que puede ayudarlo a determinar si Scrum es útil para su situación.

Haciendo explícita la metodología

Hacemos nuestro proceso explícito porque revisamos nuestro proceso con cada resumen / revisión de sprint. Parte del resumen / revisión es identificar prácticas que no funcionan para nosotros. También discutimos prácticas que creemos que funcionarán para nosotros y si hay suficiente acuerdo lo probaremos. No podríamos hacer esto sin codificar nuestra metodología.

Cerrar sesión

Este es el caballo de batalla para nuestro proceso. Esto garantiza que lo que escribimos es lo que se necesita. Cuando obtenemos una característica particular, vamos a nuestro cliente. El cliente es quien va a usar lo que está escribiendo. En algunos casos, debe delegar al cliente con alguien que lo represente (como la gestión de productos). Estos son nuestros pasos, y hasta que se complete el último paso, la función no se realiza.

• Obtenga la función del tablero, rastreador, etc.
• Ve a hablar con el cliente y comprende lo que está buscando antes de escribir cualquier cosa.
• Implementar la función.
• Mostrar al cliente la función de trabajo en su forma final Haga que el cliente cierre la sesión de la función que se está completando.

Rebanadas Verticales

Hacemos todo nuestro desarrollo en cortes verticales. Esto admite la capacidad de cerrar sesión con una función completada, así como también por estos otros motivos.

• Amortiza los problemas de integración al incorporarlos con cada función. Ayuda a eliminar el tiempo de crisis al final de un proyecto.
• Nos permite cortar características fácilmente porque eliminamos muchas de las dependencias cruzadas.
• Nos permite cortar el desarrollo si necesitamos cambiar de dirección.
• Podemos hacer lanzamientos iterativos , brindando al cliente funcionalidad temprana.

Aceptación TDD

Aprovechamos los marcos de prueba unitarios para la aceptación tdd. Esto nos da muchos beneficios.

• La reestructuración grande no cuesta mucho tiempo de reelaboración de pruebas.
• Aseguramos la funcionalidad del cliente.
• Cubrimos la integración del código.
• Apoye la práctica de desarrollo de Vertical Slice.

La compilación es siempre liberable

Después de cada impulso, el código debe ser liberable. Incluso si la función está incompleta, no se debe romper nada. Deben ejecutarse todas las pruebas y todas las funcionalidades anteriores deben estar presentes. Esto es realmente una extensión de nuestro desarrollo de corte vertical. Como tal, comparte muchos de los mismos beneficios.

• Nos permite cortar características fácilmente porque eliminamos muchas de las dependencias cruzadas.
• Nos permite cortar el desarrollo si necesitamos cambiar de dirección.
• Podemos hacer lanzamientos iterativos , brindando al cliente funcionalidad temprana.

Integración continua

Cada impulso genera una compilación a través de nuestro servidor de compilación de CI. El servidor de compilación comprueba el código, ejecuta todo el conjunto de pruebas, etiqueta el código y lo empaqueta para su implementación. Refuerza nuestra política de que la compilación siempre es liberable.

Estimación de puntos para tarjetas

Cada error, característica y tarea se convierte en "tarjeta". Una tarjeta es la unidad de trabajo lógica más pequeña que tiene algún beneficio para el cliente. Los señalamos de acuerdo con nuestra escala. Cualquiera que exceda nuestro valor máximo o se desglose aún más. Hemos encontrado que cuanto mayor es el valor del punto, más desviación puede haber en el tiempo hasta la finalización, por lo tanto, dividir las tarjetas grandes aún más. Si la tarjeta tiene suficiente ambigüedad, se redondea al siguiente valor de punto en la escala. Cada tarjeta debe ser firmada antes de que pueda considerarse completa. La estimación adecuada respalda nuestra capacidad para calcular la velocidad

Velocidad

Tenemos sprints de una semana. Todos los viernes hacemos planificación del trabajo y priorizamos el trabajo para la próxima semana. En base a nuestra velocidad, tenemos una buena idea de cuánto "trabajo" podemos lograr dentro de la semana. Nuestra velocidad es la media y la mediana de los puntos totales completados dentro de la semana. Los aumentos en la desviación estándar se analizan en busca de malas estimaciones (que siempre están tratando de mejorar) o mayores interrupciones (de las que hablo con el gerente). La velocidad también se puede usar para estimar una fecha de finalización precisa para un proyecto, pero solo si es el único proyecto en el que se está trabajando.

Mejora incremental y diseño

También tenemos una política para dejar el código en al menos un mejor estado que el que lo encontró. Refactorizar / rediseñar el código al comienzo de una tarjeta. El objetivo es dar cuenta del crecimiento orgánico que puede prevalecer con el desarrollo incremental. También refactorizamos al final por normal.

En su mayor parte, estas son las reglas que seguimos y por qué las seguimos.

Me parece que estás en un equipo muy experimentado y de alto funcionamiento. Felicitaciones, Scrum / Agile básicamente está formalizando lo que su equipo ha intuido todo este tiempo.

Creo que lo que puede ser una ventaja para su (toda) compañía es adoptar Scrum como un "terreno común", no entre los miembros de su equipo de desarrollo, sino entre su equipo de desarrollo y el departamento comercial en general .

Si bien los Scrum Sprints tienen una caja de tiempo, los equipos pueden seleccionar entre las recomendaciones que van desde dos semanas hasta 1 mes. Cualquiera menor y habría demasiadas revisiones y retrospectivas, y cualquier otra podría obstaculizar la capacidad del negocio para cambiar de dirección dentro de un año. Parece que has encontrado tu punto ideal de 1 mes, así que presiona para eso.

Hay mucho margen de maniobra para que ajuste los parámetros de Scrum y estoy seguro de que puede explicarle a su negocio que todavía está haciendo Scrum de la manera correcta. Una ventaja es que si cumple con el negocio a mitad de camino, su participación puede generar un apoyo positivo.