El equipo Scrum no sigue el principio YAGNI

13

En una reunión SCRUM, el equipo del 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 muy simple, JSON compatible con HAL que no hacía nada más que representar las cosas que estaban en las maquetas. No me dejé influenciar por las ideas futuras previstas por la gente de negocios, ya que tienen tendencia a cambiar sus ideas a menudo y decidí adoptar un enfoque minimalista. Mi propuesta fue rechazada por el equipo y me han superado las votaciones de 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 disposición del diseño. La desventaja de este 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 posibles las pruebas A / B, pero se basaron en sus predicciones solo porque no teníamos tal 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 el marketing 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 el YAGNI y KISS principios. El resto del equipo tiene un poco menos de experiencia y, aunque conocen estos principios, parece que no los entienden.

Estuvimos de acuerdo en su solución ya que el equipo en su conjunto es más importante para nosotros y no queríamos pelearnos por algo que no es tan importante. ¿Pero me temo que tal cosa pueda convertirse en un precedente para futuros debates más complicados? ¿Cómo lidiar con tal comportamiento? ¿Hay algo que yo, como líder de equipo, pueda hacer mejor?

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

    
pregunta Jacek Kobus 06.02.2017 - 20:47

8 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 tamaño de 8 o más, las posibilidades son altas, el número de programadores mediocres es mayor que el de los experimentados. Eso conducirá a menudo a situaciones donde las mejores decisiones son superadas por las mediocres. Eso no suena satisfactorio, especialmente cuando eres (o crees que eres) uno de los jugadores más experimentados, pero al menos lo mismo suele ser 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 deben mantenerse democráticas, por lo que tampoco

  • 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 "venta" de diseño o decisiones estratégicas para el equipo
  • intente cambiarse 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 entender el valor real de un enfoque minimalista y de 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 incorrectas motivadas por argumentos "por si acaso", o que contienen gran cantidad de código de marco generalizado 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.

    
respondido por el Doc Brown 06.02.2017 - 22:40
8

La compatibilidad hacia adelante es una preocupación legítima

Si uno de los siete desarrolladores que lo superaron es el arquitecto, tiene derecho a presentar NFRs como es necesario, y uno de esos NFR podría ser "compatibilidad hacia adelante", especialmente cuando está soportando un componente de sistema remoto que podría tener un calendario de lanzamiento más disperso. No quieres que los usuarios tengan que instalar una nueva versión de una aplicación porque no pensaste en el futuro.

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

Dicho esto, cualquier NFR debe documentarse como requisitos y debe tener definidos criterios de aceptación . Además, debe crear un medios de prueba . Es por eso que YAGNI es importante: no desea escribir código que no pueda probarse, y si el único propósito del código es admitir una función que nadie está usando, es difícil de probar.

No debería ser una llamada de sentencia

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

    
respondido por el John Wu 06.02.2017 - 21:32
3

Parece que su equipo de desarrollo está tratando de facilitar el equipo de producto mediante la creación de un marco que les permita hacer pruebas rápidas, que aparentemente es lo que al equipo de producto realmente le gustaría tener. Su enfoque es más como "literalmente dales lo que piden y no pienses por ellos".

Si fuera el propietario del producto, apostaría a que sería mucho más feliz si un equipo de desarrollo tomara el primer enfoque que el segundo.

    
respondido por el Martin Maat 06.02.2017 - 21:06
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.

Tu palabra, como líder de 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, debe hacer una presentación al respecto. Discuta sobre esto y muéstreles por qué es bueno.

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

    
respondido por el BЈовић 07.02.2017 - 07:02
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 modificaciones y abierto para extensión".

A menos que no "extienda" el sistema con una funcionalidad "obviamente" no solicitada, no trate con YAGNI. La introducción de abstracciones donde podría ocurrir una 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.

    
respondido por el oopexpert 07.02.2017 - 13:45
2

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

json ?? YAGNI! simplemente envía una cadena csv!

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

El rol de "Líder de equipo" no está bien definido, pero sugeriría que se aleje de expresar opiniones subjetivas sobre las elecciones técnicas de sus equipos. Incluso si sientes que están equivocados. Apégate a una lista corta de requisitos bien definidos.

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

si el equipo puede lograr aprobar pruebas para todos los requisitos comerciales y el rendimiento básico a escala requisitos técnicos, tiene un producto que funciona.

Después de eso, es solo presionar para hacer lo mismo pero más rápido

    
respondido por el Ewan 08.02.2017 - 20:34
1

Todos en el equipo deben estar de acuerdo con la definición de hecho . Sin esto, es propenso a que se produzcan enormes cantidades de alcance, puntos de vista y bastardización de los requisitos básicos.

Todo lo que se entregue por encima de este debe estar en el registro, 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.

    
respondido por el Robbie Dee 07.02.2017 - 10:55
1

Mi primer pensamiento sobre esto es ... ¿Por qué el equipo está preocupado por los cambios? ¿Tienen algún conocimiento histórico del Propietario del producto que les haga sentir que necesitan construir la primera solución para que sea un poco más configurable para facilitar futuras mejoras? Si su solución tomaría 2 días, y la de ellos 5 días, sí, es más del doble de tiempo. Pero si la alteración de su plan tomaría 2 días cada vez, pero una mejora de su plan tomaría 1 día, su plan parece ser 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 de esta mentalidad si en otras soluciones doblan el LOE sin una guía directa para hacerlo (cierta evidencia de que la complejidad adicional es necesaria para la escalabilidad, la robustez, etc.). Mi sugerencia sería incluir al propietario del producto en estas conversaciones, ya que necesitan ayudar con la priorización. Si su solución es de 5 puntos, y satisfaría la necesidad ahora, pero lo que quieran hacer requeriría 50 puntos y dos sprints o más, el PO puede decir "espera, tenemos una liberación de alta prioridad de este MVP planificada y ¡No puedo pasar 2 semanas desarrollando una funcionalidad que no está en la hoja de ruta! "

    
respondido por el Curtis Reed 23.03.2017 - 00:56

Lea otras preguntas en las etiquetas