¿Tiene sentido Scrum al implementar un nuevo backend del compilador?

Tengo un idioma existente que necesito portar a una nueva plataforma. Probablemente intentaré esto cambiando el backend del compilador existente.

Es una gran cantidad de trabajo reescribir el backend. No puedo ver una manera de dividir esto en historias sensatas sin violar los criterios de INVEST.

No puedo ver cómo cada historia puede ser negociable: todas son necesarias para un compilador que funcione. Las historias tienen la misma prioridad y no importa en qué orden las entregue. Necesito hacerlos todos.

Hay algunas partes del software que estoy implementando que son de menor prioridad que otras y puedo ver que podemos ofrecerlas de forma incremental. Sin embargo, hay un núcleo importante que debe tener .

Planeo tratar de seguir a Scrum, pero ¿solo estoy siguiendo los movimientos?

¿Existen prácticas recomendadas para este tipo de proyecto?

Tenga en cuenta que la razón principal por la que se crearon los procesos ágiles fue para hacer frente a los requisitos cambiantes. Si los requisitos se establecen en piedra (los requisitos verdaderamente fijos son raros, ¡pero lo aceptaré aquí!), Entonces algunas de las mejores prácticas para lidiar con los requisitos cambiantes, por ejemplo, historias negociables, se vuelven algo irrelevantes. Dicho esto, seguir un flujo de trabajo de Scrum todavía tiene mucho valor potencial en términos de programación y entrega de resultados. Incluso si sus entregas no constituirán un producto totalmente utilizable por un tiempo, todavía hay algo que decir para poder demostrar el progreso a su cliente (¡y al equipo!).

Considere que todas esas historias 'imprescindibles' comprenden una única epopeya: "Poder compilar en la plataforma X". En este caso, toda la epopeya debe completarse antes de entregar cualquier valor al usuario, pero este suele ser el caso al comienzo de grandes proyectos. Comience con una historia para compilar el programa más simple posible, luego cree más historias para admitir más y más características del lenguaje.

Sobre todo, no te obsesiones con tratar de forzar a cada situación a encajar en un enfoque altamente generalizado. ¡Se supone que Agile funciona para usted, no al revés!

Por supuesto, Scrum es útil. Es una metodología que hace dos cosas por ti:

1. Permite que su proyecto se adapte al cambio y
2. Le permite seguir el progreso y tener una idea de cuándo terminará

Entonces, hay algún valor en usarlo.

Creo que algunas de tus condiciones previas no son correctas y ahí es donde te estás perdiendo.

No puedo ver cómo cada historia puede ser negociable: todas son necesarias para un compilador que funcione

Esto no es verdad. Puede admitir un subconjunto del idioma y aún así tener un compilador que funcione bajo ciertas condiciones. Seguramente menos valioso que un compilador completo, pero sigue siendo valioso.

Además, no comprende lo que significa "Negociable": no significa necesariamente "Opcional" y no es necesario que las historias sean opcionales en INVEST. Una historia es un objetivo valioso y la negociación trata sobre cómo alcanzar ese objetivo. Seguramente habrá más que una forma de implementar el backend de cada función de idioma. Ahí es donde necesitas negociación.

Las historias tienen la misma prioridad y no importa en qué orden las entregue.

Esto no es correcto, como usted dice a continuación que algunas historias no son "imprescindibles", por lo que ciertamente algunas son menos valiosas. Pero incluso en la categoría "imprescindible": algunas características del lenguaje son mucho más fundamentales que otras, y de manera medible.

Una forma de medir esto es "cuánto más líneas de código podemos compilar en una base de código existente" o "cuántas pruebas más pasan" si tiene un conjunto predefinido de pruebas.

También hay otras opciones. Si estaba compilando un lenguaje tipo C, estrictamente hablando, solo necesita un bucle ify gotopara tener un lenguaje (apenas) funcional y puede implementarlo while, fory repeatcomo macros. Suponiendo que sea bastante fácil escribir un uso de un precompilador, puede tener una solución económica provisional (oye, ¿estamos negociando? :-)

En cuanto a la adaptabilidad, el soporte de un idioma es un conjunto de requisitos bastante estático, pero los idiomas también cambian y también cambia su conocimiento de sus necesidades . ¿Necesitas implementar todo? ¿Hay cosas que no necesita específicamente para sus objetivos? Uno de los inquilinos básicos de ágil es el conocimiento de tener un conocimiento incompleto, ¿puede aprovecharlo?

En conclusión, para responder a su pregunta más directamente: ¿necesita procesos ágiles cuando sus requisitos son inmutables? ¡Definitivamente no! ¿Son utilizables? ¡Probablemente si! ¿Vale la pena tu tiempo? Probablemente no, pero ¿sus requisitos son inmutables? En mis experiencias pasadas, "requisitos inmutables" => "propietario de producto perezoso", no es una regla, pero vale la pena tenerlo en cuenta.

TL; DR

Todos los controles de gestión de proyectos agregan gastos generales. No agregue gastos generales que no necesita.

Scrum es el martillo incorrecto aquí (no seas un clavo)

Scrum es un marco de gestión de proyectos en lugar de un conjunto de prácticas de desarrollo adecuadas para un desarrollador individual. A menos que esté haciendo gestión de proyectos, Scrum es probablemente la elección incorrecta.

Además, cuando dices:

Las historias tienen la misma prioridad y no importa en qué orden las entregue. Necesito hacerlos todos.

estás insinuando un par de cosas:

1. El proyecto tiene valor cero a menos que todas las historias estén 100% completas.
2. Las historias no dependen unas de otras.

Si ambas afirmaciones son ciertas, entonces realmente no tiene sentido usar un marco o práctica diseñada para priorizar el trabajo por valor u orden de dependencia.

Alternativas sugeridas

Cualquier proyecto de desarrollo podría potencialmente beneficiarse de algunas prácticas ágiles. En particular, en su caso específico, recomendaría:

1. Asegúrese de que todas sus historias tengan una "definición de hecho" que incluya pruebas de unidad y aceptación.
2. Integrar y refactorizar a menudo; no te dejes con una tarea de integración gigante al final del proyecto.

Además, incluso si su producto realmente tiene valor cero a menos que todas las historias estén hechas, pasaría algún tiempo agrupando las historias en temas que puede tratar como hitos completos. Poder decir "Completé la función foo" suele ser más útil que decir "Tengo 23/117 historias aleatorias hechas". YMMV.

Entiendo sus preocupaciones, pero creo que todavía hay valor para usted al usar scrum.

Es cierto que las historias de los usuarios son mucho más fijas que en una aplicación orientada al consumidor. Entonces ese aspecto del scrum proporcionará menos valor.

Donde creo que obtendrá valor es de los lanzamientos iterativos y frecuentes . Tener un producto potencialmente liberable al final de cada sprint lo obliga a mantener la calidad del código alta y la deuda técnica baja. También es una excelente manera de encontrar defectos temprano.

Creo que también te beneficiarías al conocer tu velocidad . Después de varios sprints, puedes ver cuántos puntos de esfuerzo tu equipo está terminando cada sprint. Esto le brinda una métrica objetiva para ayudar a determinar la fecha de envío.

Sobre todo, recuerde que ágil es adjetivo . Al final de cada sprint, debe realizar una reunión retrospectiva y luego adaptar su proceso a sus necesidades. Si hay una parte del proceso scrum que no se aplica al desarrollo del compilador, elimínelo. Si hay algún otro elemento del proceso que lo beneficiaría, agréguelo. La parte más importante de ágil en mi opinión es ser consciente de su proceso y estar constantemente mejorando para su situación específica.

(Tenga en cuenta que nunca he hecho scrum en un proyecto de compilación; siga mi consejo con un grano de sal).

Sí, siempre y cuando recuerdes que Scrum no es un conjunto de reglas estrictas a seguir. Puedes ajustarlo a tu proyecto. Los sprints, standups, scrums semanales seguirán siendo útiles para fomentar una mejor comunicación entre los miembros del equipo y para asegurarse de que el proyecto continúe en la dirección prevista.

Puede parecer que todas las historias tienen la misma prioridad, pero debe tener en cuenta la relativa dificultad de implementarlas. No querrás conservar tus objetos más difíciles hasta el final del proyecto. Deberá comenzar a trabajar en ellos lo antes posible.