Squadra di mischia che non segue il principio YAGNI

In una riunione SCRUM, il team del prodotto stava discutendo di una funzionalità di un'API che verrà utilizzata dall'app mobile. Abbiamo avuto un mock up che mostrava come dovrebbe apparire lo schermo e quali elementi chiave dovrebbe contenere (un "layout").

Sulla base di questo e della discussione che ho avuto con il proprietario del prodotto, ho creato un prototipo per una risposta API (HAL + JSON). Era un JSON molto semplice, conforme a HAL, che non faceva altro che rappresentare le cose sui modelli. Non sono stato influenzato dalle idee future previste dagli uomini d'affari in quanto hanno la tendenza a cambiare spesso le loro idee e ho deciso di adottare un approccio minimalista. La mia proposta è stata respinta dal team e sono stato superato da 7 a 1.

Il team ha deciso di utilizzare una struttura json astratta più complessa, non semantica, che consente una maggiore flessibilità nell'organizzazione del layout. Il rovescio della medaglia di questo approccio è che abbiamo finito con un insieme di oggetti uniformi che possono avere proprietà nulle e vuote in base alla progettazione. Hanno anche pensato che sarebbe stato bello rendere possibili i test A / B, ma era basato sulle loro previsioni solo perché non avevamo questo requisito.

Il più delle volte discutevamo di cose che non facevano parte dello sprint, né menzionate nei modelli. I problemi descritti erano "cosa succederebbe se il marketing in futuro ...", "cosa succederebbe se l'azienda potesse volerci ...".

Io e il proprietario del prodotto siamo programmatori esperti e abbiamo riscontrato questo tipo di problemi in passato. Cerchiamo di seguire i principi YAGNI e KISS . Il resto della squadra è un po 'meno esperto e anche se conoscono questi principi, sembrano non capirli.

Abbiamo concordato sulla loro soluzione in quanto la squadra nel suo insieme è più importante per noi e non volevamo litigare per qualcosa che non è così importante. Ma temo che una cosa del genere possa diventare un precedente per dibattiti più impegnativi e complicati? Come affrontare tale comportamento? C'è qualcosa che io, come capo squadra, posso fare di meglio?

Vale la pena ricordare che il prodotto è un MVP in fase iniziale.

Sento il tuo dolore, ci sono stato. IMHO questo tipo di problemi sono causati dal fatto che hai una squadra di 8 persone, che è già troppo grande per farti prendere sempre le migliori decisioni strategiche.

In una squadra di dimensioni pari o superiori a 8, il numero di programmatori mediocri è maggiore del numero di programmatori esperti. Ciò condurrà spesso a situazioni in cui le decisioni migliori vengono prese in considerazione da decisioni mediocri. Non sembra soddisfacente, specialmente quando sei (o pensi di essere) uno dei ragazzi più esperti, ma almeno lo stesso vale spesso per decisioni davvero sbagliate.

Il fatto è che non c'è molto che puoi fare al riguardo finché la squadra non cambia , almeno se le cose devono rimanere democratiche, quindi

• impara a conviverci
• lavorare con il team per uno o due anni, condividere le proprie competenze e sperare che imparino il valore di YAGNI e KISS nel tempo
• lavorare sulle proprie capacità di "vendere" design o decisioni strategiche al team
• prova a passare a un team diverso (forse più piccolo) in cui il tuo livello di competenza è più vicino alla media di tutto il team

Penso che l'unico modo per apprendere e comprendere il vero valore di un approccio minimalista e YAGNI sia fare alcune esperienze in prima persona. Ad esempio, impegnandosi nella manutenzione di un sistema legacy con molte previsioni "what if" errate, decisioni di progettazione errate motivate da argomenti "just in case" o contenenti un sacco di codice framework troppo generico che in realtà non è mai stato necessario. Ma non è nulla che puoi insegnare ai membri del tuo team in due giorni, alcune esperienze che le persone devono fare da sole.

La compatibilità futura è una preoccupazione legittima

Se uno dei sette sviluppatori che ti hanno superato è l'architetto, è suo diritto introdurre gli NFR secondo necessità, e uno di quegli NFR potrebbe essere "compatibilità diretta", specialmente quando stai supportando un componente di sistema remoto che potrebbe avere un più scarso programma di rilascio. Non vuoi che gli utenti debbano installare una nuova versione di un'app perché non hai pensato in anticipo.

Come altri requisiti, sono necessari criteri di accettazione

Detto questo, tutti gli NFR devono essere documentati come requisiti e devono avere criteri di accettazione definiti . Inoltre, devi trovare un modo per testarli . Questo è il motivo per cui YAGNI è importante: non vuoi scrivere codice che non può essere testato e se l'unico scopo del codice è supportare una funzionalità che nessuno sta usando, è difficile testarlo.

Non dovrebbe essere una chiamata di giudizio

Ti suggerirei di far concordare al team il requisito non detto che apparentemente ti sei perso e di farlo scrivere. Una volta definito un modo per testarlo, l'implementazione dovrebbe fallire almeno un test e quindi non dovrebbe essere una questione di voto.

Sembra che il tuo team di sviluppo stia cercando di facilitare il team del prodotto creando un framework che permetta loro di fare prove veloci, che è apparentemente ciò che il team del prodotto vorrebbe davvero avere. Il tuo approccio è più simile a "dai letteralmente ciò che chiedono e non pensare per loro".

Se fossi il proprietario del prodotto, scommetto che sarei molto più felice se un team di sviluppo adottasse il primo approccio rispetto a quest'ultimo.

Bene, la mia opinione è che la democrazia non funziona correttamente, né nel sistema politico, né in una squadra in cui la maggior parte dei programmatori è junior o mediocre.

La tua parola, come capo squadra e una delle persone più esperte in una squadra, dovrebbe avere un impatto maggiore rispetto al resto della squadra. Se YAGNI è importante per te, allora dovresti fare una presentazione al riguardo. Discutilo e mostra loro perché è buono.

Dopotutto, la tua responsabilità è più alta che per le altre persone. Non è solo per scrivere codice, ma anche per guidare le persone.

Penso che ci sia un po 'di confusione su YAGNI.

Gli sviluppatori spesso pensano di seguire YAGNI quando omettono le astrazioni che manterranno il sistema "chiuso per modifica e aperto per estensione".

A meno che non si "estenda" il sistema con una funzionalità "ovviamente" non richiesta, non si ha a che fare con YAGNI. L'introduzione di astrazioni in cui potrebbe verificarsi l'estensione è la già menzionata "compatibilità diretta".

La mia opinione personale è che solo una profonda conoscenza del dominio aiuterà a prendere decisioni di astrazione e dove trovarlo.

Il problema con YAGNI AND KISS è che sono completamente soggettivi e vaghi.

JSON ?? YAGNI! basta inviare una stringa CSV!

oggetti ?? KISSTUPID !!! usa gotos !!

Il ruolo di "Team Leader" non è ben definito, ma suggerirei che ti allontani dall'esprimere opinioni soggettive sulle scelte tecniche dei tuoi team. Anche se ritieni che abbiano torto. Attenersi a un breve elenco di requisiti ben definiti.

• unit test per il codice
• test di integrazione per apis
• test automatizzati dell'interfaccia utente per il prodotto finale
• requisiti di prestazione e ridimensionamento

se il team è in grado di superare i test per tutti i requisiti aziendali e le prestazioni di base su vasta scala, è necessario disporre di un prodotto funzionante.

Dopo di che è solo spingendo a fare lo stesso ma più velocemente

Tutti nel team devono concordare sulla definizione di fatto . Senza questo, sei soggetto a enormi quantità di scorrimento, punti di vista e bastardizzazione dei requisiti fondamentali.

Tutto ciò che viene fornito oltre a ciò deve essere nel backlog che avrà anch'esso una propria definizione di fatto.

Per quanto riguarda le priorità, il metodo MoSCoW ci ha sempre servito bene - YMMV.

Il mio primo pensiero al riguardo è ... Perché il team è preoccupato per i cambiamenti? Hanno una conoscenza storica del Product Owner che li fa sentire come se avessero bisogno di costruire la prima soluzione per essere un po 'più configurabili per facilitare i miglioramenti futuri? Se la tua soluzione richiede 2 giorni e i loro 5 giorni, sì, è più del doppio. Ma se l'alterazione del tuo piano richiederebbe 2 giorni ogni volta, ma un miglioramento al loro richiederebbe 1 giorno, il loro piano sembra più efficiente nel lungo periodo. Non penso che ci sia una decisione GIUSTA o ERRATA in questa domanda. Dipende da altri fattori, IMHO. Tuttavia, sei GIUSTO su questa mentalità se su altre soluzioni raddoppiano il LOE senza alcuna guida diretta per farlo (alcune prove che la complessità aggiuntiva è richiesta per scalabilità, robustezza ecc.). Il mio suggerimento sarebbe di portare il proprietario del prodotto in queste conversazioni, perché devono aiutare a stabilire le priorità. Se la tua soluzione è di 5 punti, e soddisferebbe ora la necessità, ma ciò che vogliono richiederebbero 50 punti e due sprint o più, l'OP potrebbe dire "aspetta, abbiamo pianificato un rilascio ad alta priorità di questo MVP e non posso passare 2 settimane a sviluppare funzionalità che non sono sulla tabella di marcia! "