Desventajas de las historias de usuario verticales

El enfoque ágil es estructurar el trabajo en historias de usuario verticales y entregar una pieza enfocada pero completamente funcional de la aplicación de principio a fin . Debido a que este es el nuevo enfoque para construir software, leí mucha literatura sobre por qué esto es mejor que las historias horizontales, pero no encuentro mucho sobre las desventajas de este enfoque.

Ya bebí el refrescante ágil y también estoy de acuerdo en que cortar el pastel verticalmente tiene muchas ventajas sobre el corte horizontal. Aquí hay una breve lista de desventajas que podría encontrar:

• Inicialmente, un desarrollador puede ser más lento en la implementación de una función porque debe comprender todas las tecnologías necesarias para desarrollar la historia (UI + capa de servicio + acceso a datos + redes, etc.)
• El diseño general de la arquitectura (estructura de la columna vertebral de la aplicación) realmente no se ajusta a este mantra (sin embargo, algunos podrían argumentar que es parte de una historia de usuario para desarrollar / cambiar la arquitectura general)

¿Cuáles son algunos inconvenientes más de cortar verticalmente historias de usuarios?

Nota: La razón por la que hago esta pregunta ahora es porque voy a intentar convencer a un equipo para que comience a escribir historias de la 'forma vertical' y quiero poder mencionar las posibles compensaciones con anticipación para que ganen No considere el enfoque un fracaso cuando se enfrentan a los inconvenientes.

No conozco ninguna desventaja a largo plazo. A corto plazo, y para un equipo nuevo en este tipo de desarrollo, la principal desventaja es que lleva un tiempo acostumbrarse y aprender.

La forma más eficiente de trabajar verticalmente es tener desarrolladores completos: de esta manera, una historia puede ser ejecutada típicamente por una persona (o más de una pero sin tareas de canalización ). Claramente, esto requiere que los desarrolladores trabajen verticalmente en la pila (desde html a la base de datos en el caso de una aplicación web).

Si su equipo no está acostumbrado a trabajar en historias verticales, es muy probable que hagan lo contrario: cada persona tendrá conocimiento de una sola capa / nivel de la aplicación solamente. Cuando presenta historias verticales, puede esperar que el equipo las divida en tareas correspondientes a capas y luego distribuya las tareas a diferentes personas. Esto será muy ineficiente.

El mejor enfoque que puedo dar con respecto a esto es tolerar esta canalización inicialmente y dejar en claro que el objetivo a largo plazo es completamente diferente. Haga que los miembros del equipo a través del programa de pares de capas para generar confianza y eventualmente permitir que las personas sean completamente independientes.

No estoy de acuerdo con la otra respuesta de que este enfoque trae deudas técnicas. Puede, pero también cualquier otro enfoque.

He estado pensando mucho en esta pregunta exacta.

Creo que es importante distinguir entre segmentar por responsabilidades individuales versus segmentar por responsabilidades de equipo. Centraré esta respuesta principalmente en cortar equipos.

Para algunos antecedentes: he trabajado en proyectos con desarrolladores full-stack, desarrolladores de un solo nivel, equipos verticales (full-stack), equipos horizontales (single-tier) y equipos diagonales. Por equipo diagonal quiero decir que contiene todos los niveles necesarios para una historia, pero no necesariamente todos los niveles en el sistema, y ​​posiblemente también contiene múltiples desarrolladores que se centran en los mismos niveles; en otras palabras, vertical en espíritu pero quizás algo horizontal en apariencia o en detalles de implementación.

Recientemente he trabajado en un grupo que pasó de equipos horizontales a equipos diagonales (casi verticales). Ha sido particularmente instructivo ver al mismo grupo de personas alineado de dos maneras diferentes. Deja algunas ventajas y desventajas bastante claras.

Completaré mi opinión hasta ahora con la siguiente comparación resumida:

Equipos horizontales

Ventajas:

• Fomenta una buena separación de las preocupaciones y niveles sueltos
• Gestión de distribución de carga de trabajo mucho más fácil
• Fácil de manejar para el líder técnico especializado
• Fomenta la colaboración dentro del nivel, las mejores prácticas, el orgullo y una cultura de excelencia
• Se alinea con patrones de comunicación naturales / emergentes.

Desventajas

• Puede conducir al aislamiento de los niveles y, por lo tanto, obstaculizar la comunicación entre niveles
• Habilita la cultura de nivel "burbuja" si no se mitiga
• Difícil de aprovechar el liderazgo generalista
• Obstaculiza a los generalistas

Equipos verticales / diagonales

Ventajas:

• Todas las partes de una historia de usuario en un equipo ("ventanilla única")
• Específicamente ayuda a entregar historias de n niveles en un solo sprint (aunque ¿realmente lo necesitas?)
• Fomenta la colaboración entre niveles y el crecimiento de habilidades generalistas
• Apoya a generalistas

Desventajas

• Gestión de distribución de carga de trabajo mucho más difícil
• Permite una separación deficiente de las preocupaciones y niveles estrechamente acoplados
• Impide la especialización al restringir la comunicación dentro del nivel; Es difícil ver cómo una cultura de excelencia podría surgir de esta estructura sin agregar comportamientos atenuantes horizontales / especializados

No creo que la membresía del equipo tenga una solución única para todos. Sin embargo, parece bastante sencillo que el equipo vertical se alinee mejor para las organizaciones que requieren generalización. Si sus ingenieros son generalistas y les gusta trabajar en stack completo, esa es una buena razón para considerar equipos verticales. El equipo horizontal se alinea mejor para organizaciones que requieren especialistas. Si sus ingenieros son especialistas, esa es una buena razón para considerar equipos horizontales.

Como otros han mencionado, las estructuras / comportamientos secundarios que cortan la otra dirección pueden ayudar a mitigar los inconvenientes de cualquiera de los sistemas. Un factor mitigante interesante es la duración del sprint. Los sprints cortos hacen que algunas de las desventajas de los equipos horizontales sean más tolerables. Si puede construir el backend esta semana y el frontend la próxima semana, ¿podría ser lo suficientemente rápido?

Para aplicar algunos de estos principios propuestos a un problema del mundo real ... Diré que los cortes horizontales han funcionado bastante bien para un equipo de desarrollo de SaaS muy real en el que he trabajado que estaba resolviendo problemas técnicos muy desafiantes en cada nivel ( donde la especialización era, en mi opinión, increíblemente importante), donde la frecuencia de entrega (y la confiabilidad a una granularidad / frecuencia alta) era crítica para el éxito del negocio. Tenga en cuenta que esta conclusión es para un equipo del mundo real muy particular, no una declaración general de superioridad del corte horizontal.

Una advertencia: probablemente estoy predispuesto en contra de creer en las afirmaciones de habilidades generalistas por parte de cualquier persona en el mundo moderno del desarrollo de software sin pruebas significativas, aunque he conocido a algunos generalistas excepcionales raros. Creo que la generalidad es un orden alto (¿vertical?) De hecho, particularmente a medida que cada nivel crece en complejidad y con la proliferación de lenguajes / plataformas / marcos / implementaciones alternativas, cada una de las cuales satisface diferentes necesidades. En estos días, especialmente, un jack de todos los oficios puede ser fácilmente un maestro de ninguno. Además, anecdóticamente, creo que la mayoría de las personas quieren especializarse un poco, de nuevo con algunas excepciones.

El gran inconveniente que he encontrado es que dificulta que un equipo construya la aplicación siguiendo un enfoque arquitectónico unificado.

En las primeras etapas del proyecto, todos escribirán sus capas de forma aislada. Las historias (y las capas involucradas) funcionarán, pero al volver a mirar el producto entregado al final del sprint, será fácil ver las pequeñas diferencias entre las ideas arquitectónicas de cada desarrollador.

Este tipo de cosas es inevitable, pero no un bloqueador. He tratado de combatir esto de dos maneras:

1. Tenga largas discusiones de diseño con el equipo antes de implementar cada historia
   • Esto se cansa rápidamente. A menudo es demasiado temprano para que alguien tome una decisión informada y luego terminas discutiendo sobre cosas que definitivamente tendrán que cambiar de todos modos.
2. Continúe y desarrolle en relativo aislamiento, teniendo en cuenta que está acumulando deudas técnicas .
   • La clave aquí es registrar la deuda técnica (arquitectónica) como un problema. Esto es algo que deberá devolverse.
   • Después de algunos sprints, será más fácil decidir sobre una arquitectura coherente y unificada. Aquí es cuando debe solicitar un sprint de refuerzo para pagar parte de su deuda técnica (refactorice el código existente). Alternativamente, puede devolverlo poco a poco en las próximas iteraciones del proyecto.

El único otro problema que se me ocurre es que generalmente hay mucho código repetitivo para agregar al comienzo de un proyecto. Escribir historias de corte vertical significa que la velocidad del equipo en las primeras historias será artificialmente baja debido a este requisito previo ... pero siempre y cuando todos sepan que esto solo debería afectar los primeros sprints, entonces todo está bien.

Tampoco conozco ninguna desventaja, sin embargo, las historias verticales se pueden implementar mal.

Cuando comencé mi carrera, me uní a un equipo que estaba ansioso por hacer XP, pero no tenían experiencia con él. Cometimos varios errores al usar historias de usuarios verticales.

Uno de los problemas que encontramos al hacer trabajo horizontal fue que las características no se integraron bien en las capas. Las API a menudo no coincidían con la especificación, las características que faltaban y muchos otros problemas. A menudo, debido a que el desarrollador de la había pasado a otra cosa, tendrías que esperar o hacerlo tú mismo.

Pasar a hacer Historias verticales resolvió estos problemas y redujo / eliminó el desperdicio de reelaborar para integrarse.

Hay una serie de prácticas de XP que admiten esta forma de trabajo. Cualquier persona debe poder trabajar en cualquier área y se espera que todos corrijan los errores que encuentren ( propiedad del Código Colectivo ).

Cuando realiza el cambio a historias verticales, puede ser complicado trabajar en áreas con las que no está familiarizado. La programación en pareja puede ayudar, si no está seguro, busque a alguien en el equipo que esté emparejado con ellos. He encontrado que la programación de pares es la forma más rápida de ponerse al día con una nueva base de código.

Sin propietarios fuertes sobre capas descubrimos que había una duplicación emergente. Aunque esto no fue un gran problema, teníamos que asegurarnos de practicar Refactor sin piedad (con las pruebas adecuadas para apoyar).

Aunque menciono varios problemas, no creo que Vertical User Stories haya sido la causa. De hecho, hizo que los problemas fueran más aparentes. Después de realizar el cambio, los problemas ya no se ofuscaron entre los equipos o las capas de aplicaciones.