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

15

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?

Dave Hillier
fuente
1
@Sklivvz actualizado tiene más sentido?
Dave Hillier
1
Como alternativa al scrum, eche un vistazo a kanban. Ambos son ágiles, pero AFAIK kanban es mejor para el tipo de trabajo que estás haciendo, mientras que scrum es mejor para el trabajo que se puede dividir en diferentes prioridades.
Izkata
@Izkata Kanban todavía espera una cola de entrada priorizada, ya sea por valor o por hora de llegada. La propuesta de valor de todo o nada es el bloqueador fundamental al considerar cualquier tipo de modelo de desarrollo iterativo.
CodeGnome
@CodeGnome Hm .. Admito no haber hecho kanban, pero entendí que es bueno para tener muchas cosas generales, como se describe en esta pregunta: Si trabajas para cada tarjeta en su propia rama, únete al tronco cuando esté completa, esa es una "iteración" / lanzamiento. Simplemente se superponían entre sí, a diferencia de los sprints en scrum.
Izkata
2
Los requisitos no cambiarán. Ya no puedes creer eso.
JeffO

Respuestas:

22

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!

vaughandroid
fuente
1
Los requisitos siempre cambian y pensar que no lo harán hasta que el código esté escrito y aprobado (suponiendo que los responsables sigan las reglas) es solo estar en el denile.
JeffO
@JeffO Estoy de acuerdo: los requisitos cambiantes son una característica buscada de ágil, por ejemplo, por eso tenemos demos.
Sklivvz
1
@JeffO Si quieres hacer trampas, los requisitos no siempre cambian, casi siempre lo hacen. Cambiaré mi redacción de todos modos.
vaughandroid
1
Encuentro esta respuesta desagradable. "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". ¡Pero es probable que requiera 6 meses de trabajo para construir un marco antes de que se pueda construir incluso el programa más pequeño! Esta no es una respuesta realista que describa el uso de un enfoque ágil para un sistema de fondo.
Dan Nissenbaum
10

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.

Sklivvz
fuente
3
+1 para " Esto no es cierto. Puede admitir un subconjunto del lenguaje y aún así tener un compilador que funcione bajo ciertas condiciones. Seguramente menos valioso que un compilador completo, pero aún valioso " . Porque eso crea una unidad comprobable y utilizable antes El fin del desarrollo.
Ross Patterson
2
Y también "Una forma de medir esto es" cuántas líneas de código más podemos compilar en una base de código existente "o" cuántas pruebas más pasan "si tiene un conjunto predefinido de pruebas". - Creo que es importante poder demostrar el progreso.
Dave Hillier
+1, aunque un punto que me falta aquí es que los requisitos para un compilador también se pueden cortar "horizontalmente" en lugar de "admite la función de lenguaje X". El compilador puede necesitar optimizar cosas (requisito propio), puede generar información de depuración (requisito propio), puede cumplir algunos requisitos de rendimiento, etc.
Doc Brown
Los requisitos de @DocBrown ciertamente pueden ser horizontales, pero las historias deben ser verticales.
Sklivvz
"Como usuario del compilador, quiero ingresar DavesCompiler -O9 program.c, y el resultado debería ser una versión altamente optimizada de program.c (sigue una definición más formal de lo que significa altamente optimizado)", me parece una historia de usuario razonable.
Doc Brown
4

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.

CodeGnome
fuente
1
No pretendí ser un desarrollador individual.
Dave Hillier el
@DaveHillier "Tengo un idioma existente ... Probablemente lo intente ... planeo seguir a Scrum". Nada de eso dice nada sobre los equipos, otras personas o la necesidad de una gestión formal del proyecto. Incluso si hay 347 de ustedes trabajando en el proyecto, la respuesta sigue siendo válida si su premisa es válida. Si no, actualice su pregunta y haré todo lo posible para actualizar la respuesta según corresponda.
CodeGnome
1
Nadie más ha hecho tal suposición. Estoy de acuerdo con algo de lo que has escrito.
Dave Hillier
44
@DaveHillier Leí tu pregunta de la misma manera que CodeGnome, que serías un desarrollador en solitario en este proyecto. El uso excesivo de en Ilugar de Wees probablemente la razón.
Izkata
Herramienta incorrecta, martillo no equivocado. Un martillo es un martillo, no todos los problemas son clavos :-)
Sklivvz
2

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).

epotter
fuente
0

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.

Mchl
fuente
Scrum is not a set of strict rules to follow- Pensé que era exactamente al revés. ¿No es como si tuviera solo unas pocas reglas, pero hay que cumplirlas (p. Ej., Standups diarios, Definición de hecho, Puntos de historia)?
Uooo
¿Estás abogando por ScrumBut ?
Dave Hillier
@Uooo solo el primero de los tres que mencionas es Scrum, el resto son solo buenas prácticas, pero no estrictamente fundamentales.
Sklivvz
@Sklivvz ¿Es por eso que muchos gerentes de proyecto piensan que "estamos haciendo standups diarios, así que estamos haciendo scrum" ? Scrum es más que solo standups diarios.
Uooo
1
@Sklivvz está bien, ahora entiendo lo que quieres decir con eso :-) Pensé que querías decir que solo hacer standups ya es scrum.
Uooo