El equipo Scrum no sigue el principio YAGNI

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.

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.

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.

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.

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.

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.

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

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.

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! "