Processo decisionale della mischia rispetto alla manutenibilità e ai tempi di sviluppo? [chiuso]

5

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:

  1. 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.
  2. 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).
  3. 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.
  4. 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!

    
posta Robin Green 05.01.2014 - 12:52
fonte

7 risposte

11

Sembra che quello che stai dicendo si riduce a:

  • Un team Scrum autogestito e autoreferenziale esiste solo quando l'intero team è esperto e impegnato.
  • In situazioni più realistiche, la gestione dovrebbe essere autorizzata a gestire la squadra e influenzare le decisioni di progettazione al fine di evitare problemi più grandi.

Se questo è giusto, allora il problema non è con Scrum, ma con il modo in cui il tuo team l'ha adottato. O

  • È ancora presto e tutti stanno ancora imparando a essere efficienti membri del team Agile; o
  • Agile e Scrum non si adattano bene alla personalità della squadra; o
  • Agile e Scrum non sono un buon abete per le richieste del progetto; o, più probabilmente
  • Agile e Scrum non sono compatibili con il concetto di gestione attuale della gestione.

Scrum e Agile non riguardano solo versioni di software iterative. Si tratta anche di migliorare il ciclo di vita dello sviluppo del software. Ogni iterazione dovrebbe apportare miglioramenti all'applicazione e, altrettanto importante, anche al processo di sviluppo. Questo significa che ci sarà un periodo in anticipo in cui le cose potrebbero non funzionare così bene, ma se la tua squadra è a bordo, le cose saranno migliori.

SE la tua squadra è a bordo. Ho visto Scrum fallire semplicemente perché qualcuno non giocava a palla. Improvvisamente, gli sforzi di 5 persone per essere Agile sono completamente deragliati perché gli incentivi di un'altra persona non si allineano con l'ethos Agile / Scrum. Non essere quella persona! Forse non ti piace quello che sta succedendo, ma perché? C'è un problema reale? Il team semplicemente non sta adottando Agile in modo efficace, oppure questo nuovo approccio è semplicemente estraneo e spaventoso?

È è abbastanza probabile che tu stia perfettamente a tuo agio con Agile e Scrum e che il tuo team stia davvero fallendo nel migliorare o consegnare. In questo caso, puoi decidere di abbandonare lo sviluppo Agile o investire più tempo e sforzi per risolvere il problema. Hai uno Scrum Master? Tutti i membri del team comprendono che cos'è lo sviluppo Agile? Di solito le persone si allontanano dallo sviluppo Agile quando pensano che le renderà più vulnerabili o responsabili. Questo non dovrebbe essere il caso, ma a volte le persone si sentono così ...

O, peggio ancora, a volte è persino vero. Chiediti se lo sviluppo del software Agile / Scrum / iterativo ha effettivamente senso nella tua situazione. Altrimenti, adottarlo potrebbe mettere la tua squadra in uno stato di stress eccessivo. Ho visto i progetti seguire uno sviluppo iterativo quando Waterfall avrebbe soddisfatto tutti molto di più. Non adottare semplicemente lo sviluppo iterativo perché è l'unica cosa. Assicurati che si adatti al tuo progetto / azienda. Se lo fa, bene! In caso contrario, trova uno stile di sviluppo e gestione che lo fa.

Ma alla fine, se scegli di seguire un approccio Agile / Scrum, assicurati che tutti siano adeguatamente istruiti sul processo, gli strumenti, gli obiettivi, i vantaggi e i sacrifici. Nella tua situazione, sembra che le persone stiano dimenticando che un processo altamente iterativo può sacrificare Design and Architecture a breve termine perché gli sprint reagiscono alle esigenze in continua evoluzione del Product Owner. Ma questi sono sacrifici a breve termine . La tua squadra dovrebbe chiedere degli sprint più duri per eliminare i debiti accumulati (che siano tecnici, architettonici, di prova, ecc.). È così che lo sviluppo Agile bilancia la reattività e la manutenibilità.

accidenti. Penso che sia tutto per ora!

    
risposta data 05.01.2014 - 13:21
fonte
8

Una delle chiavi per lo sviluppo Agile (e Scrum in particolare) è un ciclo di feedback abbreviato. Cioè, il team di sviluppo dovrebbe fornire software di lavoro ogni due o quattro settimane. Se, dopo uno o tre sprint, il team è non in consegna, la direzione sa che c'è un problema e può cambiare direzione.

Segui i tuoi scenari:

  1. Appaltatori / membri del team disinteressati. O il team non sta erogando (ottenere nuovi STET di appaltatori) o sta consegnando software non mantenibile. Questo dovrebbe entrare in evidenza abbastanza velocemente se non stanno producendo test ripetibili (automatizzati!) Che dimostrino che il software funziona davvero e se iniziano a farsi prendere dal panico quando una nuova user story richiede la rielaborazione del codice da uno sprint precedente. Scrum non nega la necessità di governance IT, e questo è particolarmente vero quando si lavora con gli appaltatori.
  2. Gli sviluppatori inesperti sono un problema indipendentemente dal progetto. La soluzione (indipendentemente dalla metodologia) consiste nel mettere almeno un programmatore esperto in ogni squadra. Ancora una volta, dovrebbe essere subito evidente che il team non sa cosa sta facendo.
  3. Masochists / Heros. Ancora una volta, la necessità di fornire software operativo ogni alcune settimane dovrebbe rendere evidente che il team sta perdendo tempo Se la squadra inizia a lavorare in orari stupidi, non lasciare che facciano tante storie al prossimo sprint.
  4. Bikeshedders Non recapito == problema risolvibile.

Una struttura di comando e controllo sui progetti in realtà non gestisce meglio questi problemi. Non può instillare il senso di proprietà necessario per il problema 1. Richiede il coinvolgimento di sviluppatori esperti (che è la soluzione per l'articolo 2 in entrambi i casi). Gioca nelle mani del masochista / aspirante eroe, sfortunatamente sfociando in situazioni ad alto rischio e software scadente. E probabilmente non mostrerà e risolverà l'incapacità del team di prendere decisioni tecniche più velocemente di Scrum.

Scrum è una metodologia fail-fast (o framework, comunque). Questa è la sua più grande forza.

    
risposta data 05.01.2014 - 18:30
fonte
3

Questo è il motivo per cui non è sufficiente concentrarsi su Scrum o sulla tecnologia: la selezione dei talenti è in parte ciò che rende o spezza il progetto. Nessuna metodologia, supervisione o politica può compensare la mancanza di talento.

Questi quattro esempi di esempi sono esattamente il motivo per cui è importante che il team includa alcuni bravi sviluppatori senior che hanno esperienza nella realizzazione di progetti complessi e che sono impegnati (attraverso interessi personali e incentivi finanziari) a garantire che il progetto rimane in pista. Il team non deve essere interamente composto da sviluppatori esperti, ma deve solo averli nelle posizioni di comando.

In caso di progetto in outsourcing, è bene essere sicuri che sia il team di outsourcing abbia le competenze e l'esperienza appropriate, sia che abbia sviluppato internamente uno sviluppatore che controlli l'output della squadra in outsourcing, possibilmente facendo un sacco di tenere, scrivere specifiche e rivedere il codice (quando il codice sorgente è parte della consegna).

    
risposta data 05.01.2014 - 19:02
fonte
3

L'argomento non è lasciare che un team incompetente si gestisca da solo? Perché qualcuno dovrebbe voler mettere in piedi un team di Scrum e riempirlo con persone che non sono in grado di fare il lavoro?

Forse questo manager con le migliori idee tecniche deve essere nel team?

Vuoi che qualcun altro faccia la scelta tecnica, ma pensi che questo team sarà in grado di sviluppare e programmare con questa tecnologia preferenziale quando tutto il team si oppone. Buona fortuna.

Non posso sostenere un argomento contro qualcosa perché ci sono situazioni in cui non funzionerà che non sono comuni. Direi che le squadre descritte in questa domanda produrrebbero un codice scadente indipendentemente dalla quantità di supervisione. Se un manager riuscisse a superare l'incompetenza di un'intera squadra, la creazione di software non sarebbe così difficile, ma non è così.

    
risposta data 06.01.2014 - 03:56
fonte
2

Sembra che l'architettura e il debito tecnico noti dibattano il tuo interesse. Non hai alcuna menzione di un "ruolo di architetto", che potrebbe essere parte del problema. Per alcune grandi risorse su "Software Architects" vedi: link . Simon Brown ha molte buone idee che cercano di affrontare molti dei problemi che stai affrontando.

Visto che sei a Londra, c'è una buona conferenza sull'architettura software a Londra ogni anno. Vedi una recensione Ho scritto sul valore della conferenza. Software Architecture Conference - London 2012 di Jamie Clayton

Vorrei anche tenere d'occhio la decisione del software per "resume padding". Molti sviluppatori a breve termine che desiderano utilizzare una combinazione di tecnologie basata su nessuna ragione commerciale diversa dal migliorare le proprie capacità.

Dopo molti anni di lavoro (lotta) con i decisori aziendali e il personale contabile / finanziario che prende decisioni aziendali (borsette strette), la manutenzione e il supporto del software è molto importante e dovrebbe essere preso in considerazione nei budget aziendali perché diventa facilmente l'80% di il costo di esecuzione del software, mentre lo Scrum / Project iniziale rappresenta il 20% nel corso della vita di una soluzione software aziendale.

Presentare al business un contratto di manutenzione / licenza interno per qualsiasi software aziendale, in quanto il 20% -30% del progetto iniziale costa annualmente. Questo è ciò che qualsiasi fornitore di software commerciale addebiterà come minimo. Se l'azienda non accetta tali costi come parte del Costo / Beneficio, allora è necessario sconsigliare il progetto (lasciare che faccia la decisione fatale).

    
risposta data 05.01.2014 - 15:47
fonte
1

Ecco alcune cose che mi sono venute in mente dopo aver scritto questa domanda:

  • Un team di sviluppo si trova spesso all'interno di un'organizzazione più grande che ha le sue politiche e pratiche (non sto parlando di cose tipo cascata "deve avere una specifica completa dei requisiti del progetto prima di scrivere il codice" che sono incompatibili con Scrum!). Potrebbero esserci dei requisiti su come o quando devono essere effettuati gli schieramenti, guide di stile di codifica o standard di codifica, ecc. - alcuni di questi potrebbero essere linee guida, alcuni potrebbero essere requisiti "da rispettare". Quindi, realisticamente, penso che Scrum riguardi il team che decide come fare le cose all'interno di quei vincoli e linee guida (e dove ritiene sia necessario, ad esempio rimuovere gli impedimenti, cercando di persuadere l'organizzazione a cambiarli ) ma non di una squadra che li ha ignorati unilateralmente . O non dovrebbe essere, comunque.
  • Un team di sviluppo non ha mai un budget assolutamente illimitato. Se un progetto o una decisione architettonica ha un impatto sul budget (ad esempio l'acquisizione di nuovi server o VM per un database NoSQL distribuito, o un tempo di sviluppo iniziale più lungo o un rischio), potrebbe essere necessario che sia approvato da qualcuno con autorità in materia di budget. Scrum non può cambiarlo.
  • La formazione , o anche solo opportunità per gli sviluppatori esperti di chattare con un team inesperto, può aiutare a evitare errori da principiante come "Lezioni di Dio".
  • La revisione del codice, la programmazione delle coppie, o anche solo il lavoro sul reciproco codice (che dovrebbe essere un evento normale a causa dell'aspetto interfunzionale di Scrum), può scoprire presto i problemi. Anche solo guardare il codice di qualcuno che non è il tuo può renderti più obiettivo sull'impatto delle decisioni di progettazione. Molti programmatori amano scavare buche nel lavoro altrui, approfittiamo di questa tendenza;)
risposta data 05.01.2014 - 15:42
fonte
0

Gli scenari che stai descrivendo possono verificarsi in qualsiasi metodologia, essi non hanno nulla a che fare con l'adattamento Scrum / Agile. Se assumi sviluppatori che hanno già lavorato in Agile Framework, molti di loro conoscono l'impatto che la loro codifica potrebbe avere sull'aspetto di manutenzione del progetto.

    
risposta data 06.01.2014 - 06:51
fonte

Leggi altre domande sui tag