Scrum team che non rispetta il principio YAGNI

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 permetterti sempre di prendere le migliori decisioni strategiche.

In una squadra di 8 o più è alta la probabilità che il numero di programmatori mediocri sia superiore al numero di esperti. Ciò condurrà spesso a situazioni in cui le decisioni migliori sono superate da quelle mediocri. Ciò non suona soddisfacente, specialmente quando sei (o pensi di essere) uno dei ragazzi più esperti, ma almeno lo stesso è spesso vero per decisioni davvero sbagliate.

Il fatto è che non c'è molto che puoi fare a meno che la squadra non cambi , almeno se le cose devono rimanere democratiche, quindi

• impara a conviverci
• lavora con il team per uno o due anni, condividi la tua esperienza e spera che imparino il valore di YAGNI e KISS nel tempo
• lavora sulle tue capacità di "vendere" il design o le decisioni strategiche al team
• prova a passare a una squadra diversa (forse più piccola) in cui il tuo livello di esperienza è più vicino alla media dell'intero team

Penso che l'unico modo per apprendere e comprendere il reale valore di un approccio minimalista e YAGNI è quello di rendere alcune esperienze di prima mano. Ad esempio, partecipando alla manutenzione di un sistema legacy con molte previsioni "what if" sbagliate, decisioni di progettazione errate motivate da argomenti "just in case" o contenenti un sacco di codice framework generalizzato che in realtà non era mai stato necessario. Ma questo non è niente che puoi insegnare ai membri del tuo team in due giorni, alcune esperienze che le persone devono fare da sole.

La compatibilità diretta è una preoccupazione legittima

Se uno dei sette sviluppatori che ti ha messo fuori gioco è l'architetto, è suo diritto introdurre NFR come necessario, e uno di questi NFR potrebbe essere "compatibilità diretta", soprattutto quando si supporta un componente di sistema remoto che potrebbe avere una pianificazione di rilascio più sparsa. Non vuoi che gli utenti debbano installare una nuova versione di un'app perché non hai pensato al futuro.

Come altri requisiti, hai bisogno dei criteri di accettazione

Detto questo, qualsiasi NFR deve essere documentato come requisiti e deve aver definito criteri di accettazione . Inoltre, devi trovare un mezzo di testarli . Ecco perché YAGNI è importante: non vuoi scrivere codice che non può essere testato, e se l'unico scopo del codice è supportare una funzione che nessuno sta utilizzando, è difficile da testare.

Non dovrebbe essere una chiamata di giudizio

Ti suggerirei di far concordare il team sul requisito inespresso che a quanto pare non hai rispettato e di farlo trascrivere. Una volta definito un mezzo per testarlo, la tua 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ù come "dargli letteralmente ciò che chiedono e non pensare per loro".

Se fossi il proprietario del prodotto, scommetto che sarei molto più felice con un team di sviluppo che ha il primo approccio rispetto al secondo.

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

La tua parola, come leader di una 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. Discutere su di esso e mostrare loro perché è buono.

Dopo tutto, la tua responsabilità è più alta di quella di altre persone. Non è solo per scrivere codice, ma anche per guidare le persone.

Pensa 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 la modifica e aperto per l'estensione".

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

La mia personale opinione è 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! invia semplicemente una stringa csv!

oggetti ?? KISSTUPID !!! basta usare gotos !!

Il ruolo di "leader del team" non è ben definito, ma ti suggerirei di prendere le distanze da esprimere opinioni soggettive sulle scelte tecniche del tuo team. Anche se senti che hanno torto. Attenersi a una breve lista di requisiti ben definiti.

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

Se il team riesce a superare i test per tutti i requisiti aziendali e le prestazioni di base ai requisiti tecnici in scala, hai un prodotto funzionante.

Dopodiché sta solo spingendo per fare lo stesso, ma più veloce

Tutti i membri del team devono concordare la definizione di fatto . Senza questo, sei soggetto a enormi quantità di creep, punti di vista e bastardizzazione dei requisiti di base.

Qualunque cosa sia consegnata al di sopra di questo deve essere nel backlog che avrà anch'essa una sua definizione di fatto.

Come per le priorità, il metodo MoSCoW ci è sempre servito bene - YMMV.

Il mio primo pensiero su questo è ... 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ù configurabile per rendere più facili i miglioramenti futuri? Se la soluzione impiegherebbe 2 giorni e il loro 5 giorni, si, è finita il doppio del tempo. Ma se l'alterazione del tuo piano richiederebbe 2 giorni ogni volta, ma un miglioramento per il loro sarebbe di 1 giorno, il loro piano sembra più efficiente nel lungo periodo. Non penso che ci sia una decisione GIUSTA o SBAGLIATA in questa domanda. Dipende da altri fattori, IMHO. Tuttavia, avete ragione riguardo a questa mentalità se su altre soluzioni raddoppieranno la LOE senza alcuna guida diretta per farlo (alcune prove dimostrano che la complessità aggiuntiva è necessaria per la scalabilità, la robustezza, ecc.). Il mio suggerimento sarebbe quello di portare il proprietario del prodotto in queste conversazioni, perché hanno bisogno di aiutare con le priorità. Se la tua soluzione è di 5 punti, e ora soddisferebbe la necessità, ma quello che vogliono fare richiederebbe 50 punti e due sprint o più, il PO potrebbe dire "aspetta, abbiamo un rilascio ad alta priorità di questo MVP pianificato e non posso spendere 2 settimane a costruire funzionalità che non sono sulla tabella di marcia! "