Apprezzo che questa domanda possa essere controversa. In un certo senso, è il rovescio della domanda " Business che cerca di fare decisioni tecniche ".
In Scrum, il team di sviluppo dovrebbe essere collettivamente responsabile di prendere decisioni di progettazione e tecniche e di codice, per soddisfare i requisiti del cliente. Esiste una divisione di responsabilità e potere tra il proprietario del prodotto, che definisce e dà priorità alle storie comunicando con le parti interessate e il team, che decide come implementare le storie.
Penso che questo sia motivato dalla convinzione che, dal momento che gli sviluppatori hanno familiarità con il codice che hanno scritto finora e tutte le informazioni che hanno memorizzato o annotato sul progetto, dovranno affrontare le conseguenze di decisioni sbagliate quando devono modificare il codice in futuro, sono nella posizione migliore per prendere decisioni di progettazione. E se con il senno di poi si rendono conto che hanno preso una decisione sbagliata, sarà un'esperienza di apprendimento molto preziosa per loro, e non saranno in grado di incolpare la direzione per ciò che è andato storto. In teoria, sono d'accordo con tutto questo. Ma (per giocare a fare l'avvocato del diavolo) posso vedere diverse situazioni in cui seguire questo principio alla lettera potrebbe essere una cattiva idea:
- Il team di sviluppo è per lo più o gli appaltatori temporanei, sono (non abbonati agli altri) che intendono saltare la nave, o stanno per essere licenziati dopo aver spedito questo progetto, o stanno per passare a un altro progetto e c'è un team completamente separato che farà "manutenzione del codice". (Un buon esempio di questo potrebbe essere: un tipico progetto di informatizzazione del governo esternalizzato.) Quindi, per uno qualsiasi di questi motivi, la squadra per lo più non sono le persone che faranno la manutenzione effettiva.
- Oppure, il team di sviluppo è tutti sviluppatori inesperti che non hanno una chiara idea dei problemi di manutenibilità che possono essere causati da pratiche di sviluppo scorrette o da decisioni di progettazione scadenti. Mentre hanno un incentivo in teoria a fare le cose giuste, l'incentivo non funziona ancora perché non sono stati bruciati abbastanza volte (o non hanno riconosciuto la connessione tra pratiche di codifica sciatta e bruciato).
- Il team di sviluppo come commette grandi errori e lavora pazzesco ore per sistemarsi o aggirarli perché (a) è un maniaco del lavoro, (b) a loro piace perdere tempo a scrivere codice boilerplate o usare qualche vecchio cattivo quadro perché dà loro un senso di sicurezza del lavoro, o (c) li fa sembrare o sembrano eroi.
- Il team ama incessantemente il bikehed, o discutere infinite infinite permutazioni di idee, o aggiungere "caratteristiche internamente visibili" che sono di basso valore, mentre il business ha davvero bisogno di loro per fornire valore più velocemente, e andiamo, è abbastanza buono è abbastanza buono!
Potrebbero esserci altri membri dell'organizzazione che potrebbero fornire una varietà di input utili nel design e nelle decisioni tecniche: sviluppatori più esperti; Sviluppatori Polyglot; Specialisti, compresi i DBA (che potrebbero non essere necessariamente nel team di scrum); I manager, che possono essere cinici e potrebbero aver visto architetture troppo ambiziose o sbagliate, vanno a male tutte le volte.
Ma non si tratta solo di ottenere input da persone con un'esperienza preziosa. Più di questo, non è fondamentalmente necessario a volte al management (a qualsiasi livello) poter dire "No, questo modo di implementarlo sarebbe una cattiva idea." In questo modo invece ", o almeno" No, puoi provarlo più tardi se c'è tempo, ma farlo inizialmente in modo più semplice "? Mi sembra che Scrum sia troppo idealista a questo riguardo. So che questo succede, ovviamente, ma dire che a causa di questa interferenza "la tua organizzazione non sta facendo Scrum" suggerisce che "fare Scrum" non è auspicabile in questi casi!