Desarrolladores de backend escritos por historias de usuarios

10

Planeaba dividir el desarrollo del backend en las historias de los usuarios verticalmente. Pero un chico de back-end de nuestro equipo comenzó a quejarse de que esto hace que su trabajo sea invisible.

Mi respuesta fue que

En las reuniones de planificación y revisión de Sprint, discutimos las tareas de backend frente a las partes interesadas para que sea visible, y
Mantener una alta calidad durante el proyecto dará como resultado un ritmo de inicio más lento que otros equipos, pero tendremos una velocidad estable durante el proyecto. Y la velocidad es muy visible para las partes interesadas.

Todavía insiste en tener historias como: "Como desarrollador, necesito tener una capa de dominio para poder encapsular la lógica empresarial".

¿Cómo puedo resolver el problema antes de que contamine al equipo?

La raíz del problema es que nuestra administración considera sistemáticamente el trabajo de backend como invisible y llama a los desarrolladores mineros respaldados, u otros términos peyorativos.

— Szili
fuente

77

No tendré las historias de back-end, no tienen sentido ... Sin embargo, no me gustaría tener ese tipo de gerentes ... Pensé que los desarrolladores de back-end eran las estrellas del rock hace algún tiempo

— margabit

2

Hacer historias de back-end separadas implica que el trabajo de back-end se puede priorizar por separado del front-end. Esto conlleva el riesgo de que las prioridades se asignen de tal manera que el trabajo de fondo quede relegado al final del trabajo acumulado hasta que se vuelva a incorporar en las historias de front-end. Por el problema con la falta de aprecio de la gerencia, le recomiendo que pregunte sobre eso en Workplace.SE.

— Bart van Ingen Schenau

Mi solución de fantasía implica abofetear ocasionalmente a todas las partes. bofetada Deja de quejarte. bofetada Deje de ignorar el papel fundamental que los datos y la lógica empresarial contribuyen al éxito del negocio que paga nuestra renta. bofetada Deja de comer los almuerzos de otras personas. No es el refrigerador de tu madre.

— Erik Reppen

1

divida los temas verticalmente, luego divida las historias resultantes en tareas horizontales.

— Jwenting

4

Hay algunas cosas mal con la situación descrita, el problema obvio es la falta de respeto dado a los desarrolladores de back-end. Como esta pregunta está etiquetada como ágil, voy a rechazar otras respuestas sugiriendo que esto es solo un problema social. Hay varios malos olores y posibles antipatrones en su historia, ninguno de los cuales tiene que ver con la gestión ignorante o incluso cómo corta las historias.

El hecho de que un grupo de personas en el equipo se sienta menospreciado por no obtener la gloria del trabajo completó varios problemas posibles.

No debería haber personas que solo hacen desarrollo de back-end. Un enfoque ágil común es tener equipos interfuncionales compuestos por especialistas en generalización que practiquen la propiedad de código compartido. Las personas no deben centrarse exclusivamente en el desarrollo de back-end o front-end, aunque ciertamente tendrán más experiencia o mejores en algunas cosas que en otras.
La arquitectura no gana valor. Desde la perspectiva del usuario, la única perspectiva que realmente importa, no importa si tiene capas o idiomas de dominio o incluso si la solución está programada. Lo único que importa es si creó valor para los usuarios. La "historia" propuesta por el desarrollador de back-end es un requisito sin sentido: es un resumen de las decisiones de diseño que, desde la perspectiva de un usuario / cliente, no hacen nada para lograr la funcionalidad deseada. En otras palabras, cualquier historia de usuario dada puede lograrse mediante cualquier número de diseños de arquitectura diferentes. Es posible que una historia de usuario se complete sin ninguna modificación en el back-end. Esto no lo convierte en una historia no válida.
Pensar sistémicamente sigue siendo crítico. Si bien la arquitectura puede no ganar valor, sigue siendo crítica para el éxito. El desarrollador de back-end tiene algunas preocupaciones válidas. Debería pensar cómo va a construir el sistema. Deberías escribir esas decisiones. Todo el sistema es importante a pesar de que solo las características de front-end son las cosas que obtendrán toda la gloria.

Mi recomendación es tratar la arquitectura como un ciudadano de primera clase , pero hacerlo de la manera correcta. Realizar un taller de atributos de calidad con las partes interesadas . Involucre a las partes interesadas clave en las revisiones de arquitectura , o al menos resuma las decisiones de diseño esenciales en hitos importantes. Dibuja la arquitectura en papel grande y hazla visible para que todo el equipo pueda verla.

Exija que todos se desarrollen en todas partes del sistema (front-end y back-end), empareje el programa si es necesario para que esto pueda suceder de manera efectiva. Continuar creando historias de usuario centradas en el usuario. Pero también identifique escenarios clave de atributos de calidad que muestren por qué el sistema está diseñado de la forma en que está e impulsa la toma de decisiones con respecto al diseño "back-end". Eleve el diseño de la arquitectura para que ya no sea invisible.

— Miguel
fuente

1

¡Gracias por una respuesta procesable! Me gustaría aclarar un poco la comprensión causada por mi redacción incorrecta. No es solo un "desarrollador de back-end", en realidad está trabajando en toda la pila, incluso en el firmware. Su punto débil es que la arquitectura del backend no recibe el reconocimiento adecuado. Y si bien la arquitectura no gana valor por sí misma, una arquitectura descuidada puede romper los sistemas o al menos puede hacer que su mantenimiento sea muy costoso. ¡Mi plan era facilitar más charlas sobre la arquitectura durante las reuniones de revisión y planificación, y el taller de calidad también parece una gran herramienta!

— Szili

FWIW, no siempre es práctico hacer que un desarrollador trabaje la pila completa. Un requisito en mi compañía actual podría involucrar el desarrollo de CICS en un mainframe de IBM, MQ, Java en Mule ESB, Datapower y, finalmente, una interfaz de usuario web rica con jquery y otras plantillas. Otra historia de usuario podría involucrar a CORBA hablando VMS COBOL, y otro backend está escrito en Gupta.

— Alan Shutko

@AlanShutko - exactamente. "El front-end de una persona es el back-end de otra persona", ¿verdad? Esta es una de las razones por las que no me gusta la jerga como "back end" y "front end", especialmente cuando se habla de múltiples componentes en un sistema. ¡Tu punto es extremadamente importante! ¡Incluso "full stack" es un término relativo que puede significar cosas diferentes en diferentes partes de un sistema!

— Michael

11

Esto parece ser un problema social, por lo que necesitará una solución social.

Si (según tengo entendido) los desarrolladores de back-end se sienten ignorados y menospreciados, y sienten que su trabajo no se valora lo suficiente, entonces hay poco que el proceso de desarrollo pueda hacer para cambiar esto.

Si entiendo correctamente, parece que los desarrolladores sienten que al menos deberían tener sus "propias" historias de usuario, para que puedan señalarlas y decir "Esto es lo que hicimos, solo nosotros backend chicos / chicas". Sin embargo, tener historias cortadas "horizontalmente" como esta es una mala idea, y estoy de acuerdo con usted en cortarlas verticalmente.

La mejor solución es probablemente tener una conversación tranquila con los desarrolladores en cuestión (individualmente o en grupo) y abordar el problema subyacente, que parece ser de respeto. En algún momento, esto probablemente tendrá que escalar a la administración.

— sleske
fuente

Gracias por las respuestas. El problema es social de hecho. Hoy hablamos sobre el argumento de ayer, y el desarrollador en cuestión me dijo que se trataba más de años de falta de respeto sistemática de su trabajo final que de su punto de vista sobre nuestro proyecto actual y su comprensión del proceso scrum. Acordamos seguir adelante con historias cortadas verticalmente.

— Szili

1

@Szili: ¿El trabajo de backend es tan malo que no merece ningún respeto, o simplemente está molesto porque no está siendo reconocido?

— Blrfl

Su trabajo de backend es excelente. El problema es el reconocimiento adecuado e incluso la gestión de la intimidación.

— Szili

4

La raíz del problema es que nuestra administración considera sistemáticamente el trabajo de backend como invisible y llama a los desarrolladores mineros respaldados, u otros términos peyorativos.

De hecho, este es el problema. ¡Es obvio que no lo resolverás con historias!

En general, una de las características del desarrollo ágil es la transparencia. Esto también significa que hace que sus problemas de organización sean más manifiestos .

La solución ágil estándar para este problema es adoptar un enfoque de desarrollo más "vertical" o "completo", donde los desarrolladores de back-end toman historias de arriba a abajo en lugar de simplemente trabajar en su zona de confort del nivel de back-end, y Los desarrolladores frontend también se extienden hacia el backend (*).

En otras palabras: haga que todos produzcan valor para sus usuarios finales.

^{(*) Nota: no todas las historias necesitan tener un componente front-end o un componente back-end. Los elementos de la interfaz de usuario se pueden reorganizar sin trabajo de fondo adicional, y el rendimiento es una característica .}

— Sklivvz
fuente

3

Parece que no tienes ninguna comprensión del desarrollo del backend. Vea cuán poco valor sirve un buen tipo de back-end cuando los chicos de front-end hacen todo el modelado de datos y la implementación lógica en el front-end y luego esperan seis meses. La mayor parte de la buena ingeniería no es buena para producir valor inmediato, se trata de producir dividendos a largo plazo. Su enfoque aplicado a la construcción de puentes haría que cada puente se hiciera solo por una semana y no tendría un plan o arquitecto porque esos no son un valor inmediato.

— Jimmy Hoffa

1

No @JimmyHoffa Estoy bastante familiarizado con el desarrollo de back-end. Mi respuesta es prácticamente un libro de texto ágil. Como notarán, no abogo por tener solo personas de front-end. Si no te gusta el ágil, no lo uses, pero simplemente estoy describiendo cómo funciona una metodología, así que no asumas cosas sobre mí o cualquier otra cosa.

— Sklivvz

2

La parte en la que se desvía es donde estás diciendo que los chicos de back-end no están produciendo valor y deberían estar haciendo trabajo de front-end, si esa no es tu intención en esta respuesta, realmente deberías reformularlo para que sea más claro lo que quieres decir aquí

— Jimmy Hoffa

1

@JimmyHoffa Pero no están produciendo ningún valor para el usuario final. Si se tratara de un equipo de desarrolladores back end, los usuarios serían los desarrolladores front-end. En ese caso, su razonamiento tendría sentido, pero no parece ser el caso.

— Sklivvz

1

Si en su mundo el valor solo se produce mediante la creación de un producto interactivo para el usuario, y los desarrolladores de back-end son innecesarios para eso, entonces en su mundo aparentemente los arquitectos y gerentes de proyecto, analistas de negocios, RRHH y todos los demás también son irrelevantes. En mi mundo, el valor se produce por la calidad de un diseño e implementación de sistemas de tal manera que el desarrollo futuro de características no implica deambular por la telaraña de una base de datos de acceso porque solo se valoró el producto que interactúa con el usuario ... La implementación de calidad es un valor . Quizás no de inmediato, pero a la larga.

— Jimmy Hoffa

1

Tus problemas son:

Tiene niveles de administración en su negocio donde no sirven para nada. Scrum, ágil, no me importa. La gestión y el desarrollo deben aislarse de las preocupaciones comerciales manejadas por un gerente de producto que tenga una pista! @ # $ Ing sobre tecnología. Tal vez funcionó para Steve Jobs, pero nunca he estado en una situación en la que los gerentes que no son expertos en tecnología estén cerca del desarrollo, fue algo saludable o, en última instancia, sirvió para producir el producto de mejor calidad que un equipo podría haber hecho.
Tienes desarrolladores que están más preocupados por las apariencias que por la resolución de problemas. Ese es un problema cultural muy serio (parece probable dado todo este fenómeno "minero") y / o tienes un problema de calidad de desarrollo, que tampoco me sorprendería dada la falta de confianza.

Saque a la gente que no necesita estar allí de la planificación y la resistencia. Cualquiera que tenga nociones de que el back-end es menos importante que el front-end es alguien que no necesita estar allí y, de hecho, está obstaculizando el proceso al estar allí.

Zanja historias. Si hablo en serio. Si están causando este tipo de problemas, tírelos por la esclusa de aire. En mi trabajo actual, nos limitamos a los criterios de "hecho" para una tarea determinada, que generalmente se centra más en la aplicación que el usuario de la misma, lo que puede ofender a aquellos que piensan que ágil (que ha estado cambiando constantemente durante 20 años) ganó " No funciona si no lo sigue al pie de la letra, pero realmente si somos profesionales, no necesitamos nada que nos cause problemas. Arrugalos, tíralos sobre tu hombro.

Y es posible que desee recordarle al desarrollador que las personas de las que realmente deben preocuparse son sus pares inmediatos, no las personas que no tienen ni idea de estar en la planificación de sprints.

— Erik Reppen
fuente

Buen consejo. Tenga en cuenta que no hay nada en el manifiesto ágil sobre "historias de usuarios" y que son solo una práctica popular que surgió con procesos específicos. Puede ser tan ágil con las historias de usuario como puede sin ...

— Michael

Esto es verdad. No estoy seguro de que el manifiesto ágil se considere lo suficiente como para "hacerlo bien" por muchos de los estándares de toda la industria de la formación que se ha desarrollado a su alrededor, pero como siempre las ideas y cuáles tienen sentido para usted y su equipo debe tener prioridad sobre las afectaciones, OMI. También obtendrá tantas respuestas de ese frente sobre cómo "hacer ágilmente" correctamente como preguntaría a los estudiantes universitarios cuáles son las reglas de las citas. No hay sustituto para el pensamiento crítico.

— Erik Reppen

No abandonaría las historias de los usuarios. En realidad, estoy trabajando duro para presentarlos, ya que tenemos la tradición de ignorar a los usuarios finales. La analogía de Steve Jobs es muy acertada ya que nuestro CEO es un tipo técnico brillante que arrancó una compañía multimillonaria. Lo único en lo que falló fue en construir una capa gerencial, por lo que permaneció muy práctico con el trabajo realizado. Esto dio paso a la aparición de la cultura estelar, lo que resulta en preocuparse por las apariencias. En resumen: tenemos un problema cultural. Pero considerándolo como dado, necesito las herramientas como las de la respuesta para dar los pasos necesarios.

— Szili

De cualquier manera, recomendaría un desarrollador de IU anal-retentivo experimentado si tiene problemas de UX. No hay sustituto que prohíba a algunos generalistas increíbles que pocos querrían pagar a un equipo completo.

— Erik Reppen