¿Es responsabilidad del propietario del producto proporcionar requisitos sobre el mapeo/transformación de datos?

Soy un ingeniero de software de pila completa. He trabajado en muchas empresas, desde compañías Fortune 100 hasta nuevas empresas, y este tema es algo sobre lo que he escuchado diferentes puntos de vista. Esta es la situación.

En un proyecto de software en el que es necesario ingerir datos de 1 sistema, implemente alguna lógica comercial en esos datos y luego envíe los datos a otro sistema para que la empresa pueda consumirlos.

En la situación anterior, ¿es responsabilidad del propietario del producto comprender cuáles son los datos que se están incorporando y también proporcionar los requisitos sobre cómo transformar/mapear esos datos para que la empresa pueda enviarlos a un sistema consumible?

Si no es responsabilidad del propietario del producto, ¿cómo se puede esperar que un desarrollador proporcione con precisión una estimación de tiempo cuando debe realizar la investigación para comprender los datos, determinar si el mapeo es posible y luego involucrar a la empresa para ver cómo funciona el mapeo? debe hacerse de una manera que proporcione valor y luego hacer el trabajo?... Dado que esto implicaría mucho descubrimiento, parece imposible dar estimaciones de tiempo precisas.

gracias de antemano

"estimaciones de tiempo precisas" es un oxímoron. ¿Está preguntando cómo estimar cuándo no se le proporcionaron los requisitos completos? Además... ¿cuál es el alcance de la estimación que necesita construir? ¿Es para planificar un Sprint o para planificar todo el proyecto?
Esto es para una planificación de sprint. Entonces, básicamente, la situación es que los desarrolladores obtienen un ticket que no tiene los requisitos anteriores y se les pide que lo señalen. Los puntos son una combinación de complejidad y tiempo. ¿Cómo puede un desarrollador tener una buena idea de cuántos puntos si no conoce los detalles mencionados anteriormente? ... Esta es la situación.
@Dan ¿Está incluyendo el riesgo y la incertidumbre en su complejidad? (Parece haber un subtexto aquí de que el propietario del producto podrá averiguar los requisitos para estos datos mejor o más rápido que usted, pero IME es la forma más rápida/más precisa de averiguar este tipo de cosas con personas técnicas que hacen el trabajo pesado con el apoyo del lado comercial. Entonces, desde una perspectiva comercial, no tendría sentido hacer que esto sea responsabilidad del propietario del producto, como tampoco el propietario del producto decidiría qué lenguaje de programación usar, etc. )
@user3067860 el riesgo y la incertidumbre no son parte de la estimación, pero la complejidad sí lo es.
@Dan Algunas guías de Scrum incluyen riesgo/incertidumbre en "complejidad". Pero supongo que podrías incluirlos en el tiempo en su lugar. Sin embargo, tiene que entrar aquí en alguna parte, ya que el promedio de historias con muchas incógnitas es que van a tomar mucho más tiempo que una historia similar que es bien conocida de antemano, no solo para la investigación, sino porque hay una alta probabilidad de encontrar algo que agregue más cosas para hacer.
@ user3067860 Esa es una buena manera de mitigar ese problema y también estar en línea con lo que otros han dicho sobre la responsabilidad.

Respuestas (4)

Hay muchas áreas grises, pero la respuesta directa a su pregunta de acuerdo con la Guía de Scrum es no: no es responsabilidad del propietario del producto proporcionar asignaciones de datos. https://scrumguides.org/scrum-guide.html#propietario-del-producto

Entonces... en su situación, el pedido de compra tiene un elemento pendiente que dice algo así como "Como ejecutivo de ventas, quiero ver un gráfico de ventas correlacionado con X datos demográficos". o algo así. Ahora bien, los equipos saben cómo funcionan esos datos (al menos lo suficientemente bien como para hacer una estimación aproximada y comenzar el trabajo) o no. Si no es así, es posible que necesite otros tipos de elementos pendientes, como picos. Un pico es un medio para reducir la incertidumbre y el riesgo.

Ahora, ¿podría hacer un pico para cada historia de usuario que aparece? Sí... pero... esta es una forma muy ineficiente de trabajar. Un buen experto en scrum alentará al equipo a explorar lo que pueden hacer para simplificar sus sistemas de datos o generar conocimiento en áreas comúnmente aprovechadas para que esto no siempre suceda.

Gracias. Pero no veo la pregunta que hice como respondida en ese enlace.
También publicaría una pregunta de seguimiento. Digamos, por ejemplo, que esto es correcto y que el PO no es responsable de las asignaciones. ¿Son responsables de comprender los datos de entrada y de salida lo suficientemente bien como para poder determinar si un mapeo que hacen los desarrolladores es correcto?
El PO no tiene que hacerlo, no. Los desarrolladores (dev, control de calidad, etc.) son responsables de crear un producto que funcione. El PO es más responsable de la participación de las partes interesadas, priorizando el trabajo atrasado, etc. PO es "qué", Dev es "cómo". Dicho esto, es increíblemente útil tener un PO que tenga ese conocimiento, pero no es obligatorio.
Dicho de otra manera, prefiero tener un PO que entienda la necesidad del negocio, que pueda traer a la mesa a las partes interesadas adecuadas, que se respeten sus decisiones y que confíe en que el equipo hará un buen trabajo, pero que no tenga conocimientos técnicos, que tener un PO que realmente conoce el lado técnico y no puede hacer el otro, porque entonces nadie en el equipo puede hacer las otras cosas. Pero tener ambos es increíble.

La confianza es la base de la agilidad. La falta de confianza está pintada en toda la forma en que se enmarca la pregunta.

De hecho, el Product Owner es responsable de impulsar la creación de las historias de usuario. El PO, sin embargo, no es el único responsable de eso. Especialmente en las Historias que tienen una cantidad considerable de antecedentes técnicos, el equipo de desarrollo debe desempeñar un papel crítico y activo para comprender los requisitos e identificar posibles brechas.

No es responsabilidad de la OP anotar los requisitos hasta el último detalle. Es responsabilidad de Desarrollo comprometerse y estar dispuesto a construir, colaborar con la OP sobre cómo se pueden cumplir los requisitos de manera evolutiva.

En pocas palabras, el PO es responsable de contarle una historia sobre lo que se necesita y responder a todas las preguntas sobre lo que se necesita . Depende del equipo de desarrollo hacer las preguntas correctas para acordar dentro del equipo de desarrollo cómo se implementará la solución. A la OP no le preocupa cómo se implementará la solución. Es responsabilidad del equipo de desarrollo asegurarse de que la forma en que se construye el código cumpla con los estándares esperados por el equipo .

Como se enmarca la pregunta, no hay un equipo ágil. Hay un analista funcional que pasa los requisitos al equipo de desarrollo con un enfoque muy similar al de una cascada.

Gracias por su respuesta. Sin embargo, el núcleo de la pregunta no se trata de cumplir con todos los requisitos del ticket, sino de comprender la lógica/proceso comercial en torno a los datos. ¿Está diciendo que no es responsabilidad de las OP comprender la lógica comercial/los procesos de los datos entrantes/salientes y cómo se procesan los datos?
@Dan Eres un equipo. No necesita saber de plomería.
@Dan, es función de PO comprender los requisitos comerciales . Lo más probable es que esta interfaz exija una API para poder intercambiar datos. La forma en que se implementará la API requerirá conocimientos técnicos. Es probable que el pedido de compra diga "necesita consumir información XYZ". "¿Te preguntarás cómo ?". Él responderá "ayúdame a resolverlo".
Recuerde, el PO dice lo que debe hacerse. Su pregunta se centra mucho más en cómo (porque su preocupación subyacente no está en el requisito, sino en la estimación ).
@TiagoCardoso La pregunta de cómo es con respecto a cómo puedo dar un buen tiempo estimado para completar este trabajo si no conocemos esos detalles y el PO no los ha proporcionado.
@TiagoCardoso Todavía no escuché respuesta al papel. ¿Es responsabilidad del propietario del producto comprender los datos a medida que se incorporan y cuál es el resultado valioso desde el punto de vista empresarial?
Hola @Dan, gracias por los comentarios. He ampliado un poco mi respuesta. Espero que esto quede claro.

Si una empresa necesita lidiar mucho con este tipo de historias técnicas, contrata/tiene propietarios de productos técnicos. Si tales historias surgen de vez en cuando, los propietarios de productos preparan las historias con el apoyo de los desarrolladores de software del equipo.

Entonces, mi respuesta es; esto está completamente dentro del alcance del rol del propietario del producto.

Bienvenido a PMSE. Tu última frase parece contraria a la anterior. El equipo en su conjunto contribuye al refinamiento de la cartera de pedidos (refinamiento es el término preferido en lugar de preparación)
Me gusta más tu respuesta debido a mi parcialidad, pero no contaminaré la votación positiva por eso. ja ja. Voy a dejar esto reposar durante una semana más o menos y aceptaré el que tenga más votos, el mío no incluido.

El equipo en su conjunto es responsable de los requisitos y especificaciones. El refinamiento de la cartera de pedidos (preparar elementos de la cartera de pedidos para que estén listos para participar en futuros sprints) es un proceso continuo. Algunos equipos asignan formalmente una cierta cantidad de tiempo cada sprint para el refinamiento de la cartera de pedidos o, alternativamente, simplemente lo hacen como una tarea en segundo plano.

Sin embargo, el punto del refinamiento de la cartera de pedidos es que la historia está lista para comenzar , no que esté detallada de manera integral en cada detalle. Con respecto a la estimación, el equipo solo necesita suficiente información para juzgar si una historia es lo suficientemente pequeña como para hacerla en un solo sprint o si necesita desglosarse más. En el caso de una transformación, puede ser suficiente conocer el número y tipo de fuentes, el número de atributos y tal vez el tipo de cálculos que podrían ser necesarios, pero quizás no sea necesario conocer cada elemento del mapeo para que la historia sea listo.

¿Es responsabilidad del propietario del producto proporcionar requisitos sobre el mapeo/transformación de datos?
RespuestasAquíPolítica de privacidad1y, 0v