Agile: Historias de usuarios para el proyecto de aprendizaje automático?

Question

Acabo de terminar con una implementación prototipo de un algoritmo de aprendizaje supervisado, asignando automáticamente etiquetas categóricas a todos los elementos en la base de datos de nuestra compañía (aproximadamente 5 millones de elementos).

Los resultados se ven bien, y me han dado luz verde para planificar el proyecto de implementación de producción.

He hecho este tipo de trabajo antes, así que sé cómo los componentes funcionales del software. Necesito una colección de rastreadores web para buscar datos. Necesito extraer características de los documentos rastreados. Esos documentos deben segregarse en un "conjunto de capacitación" y un "conjunto de clasificación", y los vectores de características deben extraerse de cada documento. Esos vectores de características se autoorganizan en grupos y los clústeres se pasan a través de una serie de operaciones de reequilibrio. Etc, etc. etc. etc.

Así que armé un plan, con aproximadamente 30 tareas únicas de desarrollo/implementación, cada una con estimaciones de tiempo. La primera etapa de desarrollo, ignorando algunas características avanzadas que nos gustaría tener a largo plazo, pero que aún no es lo suficientemente alta como para incluirla en el cronograma de desarrollo, está programada para dos meses de trabajo. . (Tenga en cuenta que ya tengo un prototipo funcional, por lo que la implementación final es significativamente más sencilla que si el proyecto comenzara desde cero.)

Mi gerente dijo que el plan le parecía bueno, pero me preguntó si podía reorganizarlo. las tareas en historias de usuarios, por varias razones: (1) nuestro software de gestión de proyectos está totalmente organizado en torno a historias de usuarios; (2) toda nuestra programación se basa en ajustar cuentos completos de usuarios en sprints, en lugar de tareas de programación individual; (3) otros equipos, como los desarrolladores web, han hecho un gran uso de metodologías ágiles, y se han beneficiado al modelar todas las características del software como historias de usuarios.

así que creé una historia de usuario en el nivel superior del proyecto:

Como usuario del sistema, quiero buscar elementos por categoría, por lo que puedo encontrar fácilmente los elementos más relevantes dentro de una base de datos enorme y compleja.

O tal vez una historia mejor de nivel superior de esta función sería:

Como editor de contenido, quiero crear automáticamente designaciones categóricas para los artículos en nuestra base de datos, por lo que los clientes pueden fácilmente encuentre datos de alto valor dentro de nuestra enorme y compleja base de datos.

Pero ese no es el problema real.

La parte engañosa, para mí, es descubrir cómo crear historias de usuario subordinadas para el resto de la arquitectura de aprendizaje automático.

Caso en punto ... Sé que el algoritmo requiere dos subdivisiones arquitectónicas principales: (A) entrenamiento y (B) clasificación. Y sé que la parte de capacitación de la arquitectura requiere la construcción de un espacio de clúster.

Toda la literatura de desarrollo ágil que he leído parece indicar que una historia de usuario debe ser la "implementación más pequeña posible que ofrece valor comercial". Y eso tiene mucho sentido cuando se diseña una pieza de software para el usuario final. Comience de a poco y luego incremente el valor cuando los usuarios demanden funcionalidades adicionales.

Pero un espacio de clúster, en sí mismo, proporciona cero valor comercial.Tampoco lo hace un rastreador, o un extractor de funciones. No hay valor comercial (no para el usuario final ni para ninguno de los roles internos de la empresa) en un sistema parcial . Un espacio de clúster entrenado solo es posible con el rastreador y el extractor de funciones, y solo es relevante si también desarrollamos un clasificador acompañante.

supongo que sería posible crear historias de usuario, donde los componentes subordinados del sistema actúan como los usuarios en las historias:

Como supervisado-learning rutina de construcción clúster de espacio, que quiere consumir datos de un extractor de características, para que yo pueda existir.

Pero eso parece realmente extraño. ¿Qué beneficio me proporciona como desarrollador (o nuestros usuarios, o cualquier otra parte interesada, para el caso) para modelar mis historias de usuario de esa manera?

Aunque la historia principal se puede dividir fácilmente a lo largo de los límites del componente arquitectónico (rastreador, entrenador, clasificador, etc.), no puedo pensar en ninguna descomposición útil desde la perspectiva del usuario.

¿Qué piensan? ¿Cómo se planifican las historias de usuario Agile para componentes sofisticados, indivisibles y sin uso del usuario?

Answer 1

Cualquier historia tiene un rol, una acción y un objetivo. Por lo tanto, piense en escribir una historia que nombre un Rol (un A/k/A Actor) haciendo algo para lograr un objetivo.

Lo que pone debe tener una prueba obvia, es decir, un procedimiento de decisión eficaz que define el éxito y el fracaso.

Donde se encuentre con problemas aquí, creo, se está viendo atrapado en el "valor comercial". Comience definiendo en general cómo sabrá cuándo completó su tarea con éxito. Entonces, "Achives Business Value" está haciendo un cierto progreso hacia la meta.

Tienes que ser un poco creativo con algunas cosas en Agile, porque a menudo están orientadas hacia los procesos de negocios.

Actualización:

varios puntos aquí.

1. es un teorema que si no se puede observar ningún efecto de un componente de fuera del sistema, entonces ese componente puede ser retirado sin efecto en el sentido de la equivalencia observacional.

2. Se define una cosa, generalmente llamada tarea , que es una asignación de programador más pequeña que una historia de usuario. Si tienes algo que parece una gran historia, divídelo como una tarea. SIN EMBARGO, hágalo de forma que tenga un comportamiento externo bien definido, O créelo en un contexto en el que pueda observar su comportamiento.

por lo que hay un par de posibles enfoques que se encomiendan a mí:

1. Establecer grandes historias y dividirlos en un número inusualmente grande de pasos secundarios

2. Descomponer las historias , tal vez mediante la partición del conjunto de datos.Entonces, por ejemplo, para descomponer "Etiquetas de solicitud de usuario actualizadas", descomponga los datos de prueba para que solo tenga datos que recibirían la etiqueta α y haga una historia "El usuario solicita etiquetas actualizadas al α". Como sabe que todo será un α, construye el código más simple que siempre asigna alfa, y se preocupa por el código que selecciona.

Answer 2

Puede ser útil utilizar el concepto de 'divisiones verticales'. Imagine una aplicación simple de 3 capas (UI/Logic/DB, por ejemplo). En lugar de construir una capa, luego otra, 'cortar' verticalmente a través de los tres. Una historia inicial podría ser "Como usuario, quiero poder iniciar sesión en el sistema para poder acceder a él". Cuando termine, esta historia es potencialmente enviable, ya que brinda una funcionalidad completa, pero es muy poco probable que proporcione el valor suficiente al cliente para que realmente valga la pena el envío. Uno de los beneficios de las divisiones verticales es que ha aprendido algo sobre todas las capas, conocimiento que puede usarse en futuras iteraciones.

Si no está familiarizado con él, el modelo INVEST es muy útil para historias de los usuarios:

I - Independiente

N - Negociable

V - Valioso

E - Estimado

S - Tamaño adecuado

T - Testable

Answer 3

Creo que también puede medir resultados correctos o incorrectos para un sistema parcial. Debe anular otros componentes del sistema. Ciertamente es posible. Además, en mi opinión, tiene sentido que una parte del sistema sea un actor de otros módulos.