El equipo Scrum no sigue el principio YAGNI

13

En una reunión SCRUM, el equipo de producto estaba debatiendo sobre una característica en una API que será consumida por la aplicación móvil. Tuvimos una maqueta que mostraba cómo debería verse la pantalla y qué elementos clave debería contener (un "diseño").

Basado en esto y en la discusión que tuve con el propietario del producto, creé un prototipo para una respuesta API (HAL + JSON). Era un JSON muy simple y compatible con HAL que no hacía más que representar las cosas que estaban en las maquetas. No me influyeron las ideas futuras que preveían los empresarios, ya que tienden a cambiar sus ideas a menudo y decidí adoptar un enfoque minimalista. Mi propuesta fue rechazada por el equipo y me votaron 7 a 1.

El equipo decidió utilizar una estructura json abstracta más compleja y no semántica, que permite una mayor flexibilidad en la organización del diseño. La desventaja de ese enfoque es que terminamos con un conjunto de objetos uniformes que pueden tener propiedades nulas y vacías por diseño. También pensaron que sería bueno hacer posible la prueba A / B, sin embargo, se basó en sus predicciones solo porque no teníamos ese requisito.

La mayoría de las veces debatíamos sobre cosas que no formaban parte del sprint ni se mencionaban en las maquetas. Los problemas descritos fueron "qué pasaría si la comercialización en el futuro ...", "qué pasaría si la empresa quisiera que ...".

Yo y el propietario del producto somos programadores experimentados y hemos visto este tipo de problemas en el pasado. Intentamos seguir los principios de YAGNI y KISS . El resto del equipo tiene un poco menos de experiencia y, aunque conocen estos principios, parecen no entenderlos.

Acordamos que su solución como equipo en su conjunto es más importante para nosotros y no queríamos pelear por algo que no es tan importante. Pero me temo que tal cosa puede convertirse en un precedente para los próximos debates más complicados. ¿Cómo lidiar con tal comportamiento? ¿Hay algo que yo, como líder del equipo, pueda hacer mejor?

Vale la pena mencionar que el producto es un MVP en etapa inicial.

Jacek Kobus
fuente
11
I'm afraid if such thing can become a precedence for upcoming, more complicated debates?- Eso también viola a YAGNI: preocuparse por un futuro que podría no suceder. Si iba a mantenerse firme, ya debería haberlo hecho.
Robert Harvey
@gnat: Esto no parece ser sobre limitaciones de tiempo.
Robert Harvey
¿Cumplir con HAL no está sujeto a YAGNI?
Mateo
@Matthew tomó todo una semana y también preparé otro prototipo usando JSON simple para deshacerme de HAL, pero también fue rechazado visto como "no lo suficientemente flexible". El equipo lo modificó y finalmente se utilizó esa versión modificada. El HAL funciona para nosotros como un estándar, un conjunto de pautas, y es más fácil para mí imponer una estructura uniforme en todos los puntos finales. La API anterior no estaba usando ningún estándar y no terminó bien.
Jacek Kobus
55
La flexibilidad agrega complejidad. Mientras el equipo lo entienda, uno puede avanzar.
Jon Raynor

Respuestas:

10

Siento tu dolor, he estado allí. En mi humilde opinión, este tipo de problemas son causados ​​por el hecho de que tiene un equipo de 8 personas, que ya es demasiado grande para permitirle tomar siempre las mejores decisiones estratégicas.

En un equipo de 8 o más posibilidades, el número de programadores mediocres es mayor que el de los experimentados. Eso a menudo conducirá a situaciones en las que las mejores decisiones son superadas por las mediocres. Eso no suena satisfactorio, especialmente cuando eres (o piensas que eres) uno de los muchachos más experimentados, pero al menos lo mismo es a menudo cierto para decisiones realmente malas.

El hecho es que no hay mucho que puedas hacer al respecto mientras el equipo no cambie , al menos si las cosas se mantienen democráticas, entonces

  • Aprende a vivir con ello
  • trabaje con el equipo durante uno o dos años, comparta su propia experiencia y espere que aprendan el valor de YAGNI y KISS con el tiempo
  • trabaje en sus propias habilidades de "vender" diseño o decisiones estratégicas al equipo
  • intente cambiar a un equipo diferente (quizás más pequeño) donde su propio nivel de experiencia esté más cerca del promedio de todo el equipo

Creo que la única forma de aprender y comprender el valor real de un enfoque minimalista y YAGNI es haciendo algunas experiencias de primera mano. Por ejemplo, al involucrarse en el mantenimiento de un sistema heredado con muchas predicciones erróneas de "qué pasaría si", decisiones de diseño erróneas motivadas por argumentos "por si acaso", o que contienen un montón de código de marco sobregeneralizado que en realidad nunca fue necesario. Pero eso no es nada que pueda enseñar a los miembros de su equipo en dos días, algunas experiencias que las personas tienen que hacer por sí mismas.

Doc Brown
fuente
55
La mayoría de las personas tienen que tocar la estufa para saber que hace calor y no tocarla. El software es muy parecido. ++
RubberDuck
2
Mantener un registro / diario del proyecto es clave para este tipo de cosas. Una vez que haya grabado las diversas discusiones que han tenido lugar, son mucho más concretas que los recuerdos de las conversaciones de las personas meses o años después. Hay una buena pregunta sobre la práctica aquí .
Robbie Dee
@RobbieDee: claro, si ayuda al equipo a aprender sobre YAGNI y KISS.
Doc Brown
3
La tercera viñeta (trabajando en sus propias habilidades para "vender" un diseño) no recibe suficiente atención. Es por eso que los desarrolladores aún necesitan tener (o trabajar) buenas habilidades de comunicación.
Randall Stewart
@RandallStewart: absolutamente. Pero incluso con las mejores habilidades de comunicación, puede ser difícil vender YAGNI a personas que no han hecho algunas experiencias por sí mismas, o confundirlo con "rápido y sucio", o que se les educó con la idea de que "la abstracción es (siempre) buena" y así que intente abstraer cosas por el bien de la abstracción en lugar de la simplificación. La comunicación necesita dos lados: uno que pueda explicar bien las cosas y otro que esté dispuesto a escuchar y comprender.
Doc Brown
8

La compatibilidad directa es una preocupación legítima

Si uno de los siete desarrolladores que lo votó es el arquitecto, es su derecho introducir NFR según sea necesario, y uno de esos NFR podría ser la "compatibilidad hacia adelante", especialmente cuando se admite un componente de sistema remoto que podría tener un alcance más escaso Calendario de lanzamiento. No desea que los usuarios tengan que instalar una nueva versión de una aplicación porque no pensó en el futuro.

Al igual que otros requisitos, necesita criterios de aceptación.

Dicho esto, cualquier NFR debe documentarse como requisito y debe tener criterios de aceptación definidos . Además, debe encontrar un medio para probarlos . Es por eso que YAGNI es importante: no desea escribir código que no se pueda probar, y si el único propósito del código es admitir una característica que nadie está usando, es difícil de probar.

No debería ser un juicio

Le sugiero que haga que el equipo acepte el requisito tácito que aparentemente no cumplió y que lo anote. Una vez que haya definido un medio para probarlo, su implementación debería fallar al menos una prueba y, por lo tanto, no debería ser cuestión de votación.

John Wu
fuente
1
¿En qué parte de la pregunta leyó que el equipo de OP dejó el camino de YAGNI debido a un requisito de compatibilidad directa?
Doc Brown
La compatibilidad hacia adelante es para lo que sirve el Content-Typeencabezado
Jack
2
Estoy dispuesto a llamarlo de otra manera si lo desea, tal vez extensibilidad. El punto es el mismo; sigue siendo un NFR.
John Wu
1
Hay dos formas de hacer que un sistema sea extensible. La primera forma es prever muchos cambios potenciales en los requisitos y hacer que las cosas sean altamente configurables "por si acaso". Estoy seguro de que uno puede inventar muchas pruebas de aceptación para este tipo de extensibilidad. O, manteniendo las cosas lo más simple posible, de modo que la base del código sea pequeña, fácil de entender, y los puntos de extensión o abstracciones se puedan agregar más tarde cuando realmente se necesiten. Esto último no es nada para lo que pueda (o necesite) escribir pruebas. Por lo tanto no creo que esto se puede solucionar fácilmente "escribiendo NFR tácitas abajo" ...
Doc Brown
... así que se trata más de cómo evitar que un equipo de desarrolladores creativos haga suposiciones sobre NFR e invente algunos.
Doc Brown
3

Parece que su equipo de desarrollo está tratando de facilitar al equipo de producto creando un marco que les permita realizar pruebas rápidas, que aparentemente es lo que al equipo de producto realmente le encantaría tener. Su enfoque es más como "literalmente déles lo que piden y no piense por ellos".

Si fuera el propietario del producto, apuesto a que estaría mucho más feliz con un equipo de desarrollo que adoptara el primer enfoque que el último.

Martin Maat
fuente
3
+1 anticipar y planear el cambio no es lo mismo que convertirse en astronauta de arquitectura completa y crear una plataforma interna . Un poco de trabajo en este momento puede evitar mucho trabajo en el futuro. Si bien el equipo de OP quizás se está inclinando demasiado en la dirección de los hipotéticos, un enfoque fundamentalista de YAGNI es ciertamente subóptimo.
amon
44
Parece más que felizmente votarías al OP y cometerías los mismos errores de planificación para "qué pasaría si la comercialización en el futuro ..." que el resto del equipo. Cuando las personas comienzan a construir marcos en lugar de software de aplicación cuando la tarea es construir software de aplicación, casi siempre lo están haciendo mal.
Doc Brown
@DocBrown Técnicamente estaría de acuerdo. Sin embargo, este caso parece ser sobre la voluntad de facilitar frente a exigir respeto personal. Ser "correcto" por un lado versus ser útil o útil por otro lado. Lo que leí entre líneas es que el OP está perdiendo terreno y elige impulsar su ego al subrayar su experiencia ante una audiencia en línea en lugar de contribuir en un entorno en el que ya no se siente cómodo. Esta dinámica es típica de la introducción de scrum.
Martin Maat
@MartinMaat Estaba un poco decepcionado por el hecho de que no estaban de acuerdo conmigo. No entendí por qué sucedió. Durante el trabajo diario los ayudo con las revisiones de código, etc. A menudo discutimos pero me gusta, porque el resultado final es mejor; Sé que respetan mi opinión; Siempre trato de usar argumentos válidos que respalden mis teorías. Al final, eligen la mejor opción y también se hacen responsables. El equipo hizo lo que se suponía que debía hacer: resolvió el problema. Fue mi error y el del propietario del producto, que el asunto era demasiado amplio y mal descrito desde el principio.
Jacek Kobus
2

Bueno, mi opinión es que la democracia no funciona correctamente, ni en el sistema político ni en un equipo donde la mayoría de los programadores son jóvenes o mediocres.

Su palabra, como líder del equipo, y una de las personas más experimentadas en un equipo, debería tener un mayor impacto que el resto del equipo. Si YAGNI es importante para usted, entonces debe hacer una presentación al respecto. Discuta al respecto y muéstreles por qué es bueno.

Después de todo, su responsabilidad es mayor que para otras personas. No es solo escribir código, sino también guiar a las personas.

BЈовић
fuente
3
La democracia es probablemente la causa del problema aquí, pero no ser democrático es, en mi humilde opinión, ninguna solución, porque puede introducir fácilmente problemas más grandes que los descritos en la pregunta: en realidad puede arruinar al equipo.
Doc Brown
@DocBrown Acabas de contradecirte en la misma oración. En mi opinión, algunas decisiones no dependen de las personas para decidir. Lo que OP explicó es uno de ellos. Para citar a Armstrong para las personas que no usan YAGNI: Querías un plátano pero lo que obtuviste fue un gorila sosteniendo el plátano y toda la jungla
BЈовић
2
No, esto no es una contradicción (tal vez no expresé bien mi punto). Las cosas no siempre son "en blanco y negro". Solo porque la democracia no funciona bien en algunas situaciones, no ser democrático no es una garantía para mejorar la situación y mejorar las cosas. A menudo no es tan simple.
Doc Brown
1
Con la democracia no necesariamente se obtiene lo "correcto", se obtiene lo que la mayoría de las personas acuerdan. Y esto puede ser defectuoso. Y a menudo lo "correcto" tiene un problema con la aceptación social. YAGNI no debe ser esposas que le impidan introducir abstracciones adecuadas que le permitirán agregar fácilmente el "gorila" o la "jungla entera" si es necesario.
oopexpert
@oopexpert El problema es: puede que los necesite. YAGNI habla en contra de la ingeniería. Las abstracciones adecuadas son una cosa, agregar cosas que quizás no necesites son diferentes.
B 13овић
2

Creo que hay una pequeña confusión sobre YAGNI.

Los desarrolladores a menudo piensan que siguen a YAGNI cuando omiten abstracciones que mantendrán el sistema "cerrado para modificación y abierto para extensión".

A menos que no "extienda" el sistema con una funcionalidad "obviamente" no solicitada, no trata con YAGNI. La introducción de abstracciones donde podría ocurrir la extensión es la ya mencionada "compatibilidad hacia adelante".

Mi opinión personal es que solo un conocimiento profundo del dominio ayudará a tomar decisiones de abstracción y dónde ubicarlo.

oopexpert
fuente
2

El problema con YAGNI Y KISS es que son completamente subjetivos y vagos.

json ?? YAGNI! solo envíe una cadena csv!

¿¿objetos?? KISSTUPID !!! solo usa gotos !!

El rol de 'Líder de equipo' no está bien definido, pero le sugiero que se distancie de expresar opiniones subjetivas sobre las elecciones técnicas de su equipo. Incluso si sientes que están equivocados. Apéguese a una breve lista de requisitos bien definidos.

  • pruebas unitarias para el código
  • pruebas de integración para apis
  • pruebas automatizadas de IU para el producto final
  • requisitos de rendimiento y escala

Si el equipo puede lograr pasar las pruebas para todos los requisitos comerciales y el rendimiento básico a escala, los requisitos técnicos tienen un producto que funcione.

Después de eso solo está presionando para hacer lo mismo pero más rápido

Ewan
fuente
1

Todos en el equipo deben estar de acuerdo con la definición de hecho . Sin esto, eres propenso a grandes cantidades de desplazamiento del alcance, puntos de vista y bastardización de los requisitos básicos.

Todo lo que se entregue más allá de esto debe estar en la cartera de pedidos, que también tendrá su propia definición de hecho.

En cuanto a las prioridades, el método MoSCoW siempre nos ha servido bien: YMMV.

Robbie Dee
fuente
1

Mi primer pensamiento sobre esto es ... ¿Por qué el equipo está preocupado por los cambios? ¿Tienen alguna comprensión histórica del Propietario del producto que les hace sentir que necesitan construir la primera solución para ser un poco más configurables para facilitar futuras mejoras? Si su solución demoraría 2 días, y sus 5 días, sí, es más del doble. Pero si la alteración de su plan demoraría 2 días cada vez, pero una mejora de su plan demoraría 1 día, su plan parece más eficiente a largo plazo. No creo que haya una decisión CORRECTA o INCORRECTA en esta pregunta. Depende de otros factores, en mi humilde opinión. Sin embargo, tiene razón sobre esta mentalidad si en otras soluciones duplican la LOE sin ninguna orientación directa para hacerlo (alguna evidencia de que se requiere la complejidad adicional para la escalabilidad, robustez, etc.). Mi sugerencia sería llevar al propietario del producto a estas conversaciones, porque necesitan ayudar con la priorización. Si su solución es de 5 puntos, y satisfaría la necesidad ahora, pero lo que quieren hacer requeriría 50 puntos y dos sprints o más, la OP puede decir "espera, tenemos planeado un lanzamiento de alta prioridad de este MVP y ¡no puedo pasar 2 semanas desarrollando funciones que no están en la hoja de ruta! "

Curtis Reed
fuente