Quale di questi è più importante? Squadra esperta o buona pratica di processo?
Quando dico esperto, intendo membri logici e creativi con buone capacità di codifica e test. Un buon processo sarebbe la metodologia di sviluppo, come agile, scrum, ecc.
Quale di questi è più importante? Squadra esperta o buona pratica di processo?
Quando dico esperto, intendo membri logici e creativi con buone capacità di codifica e test. Un buon processo sarebbe la metodologia di sviluppo, come agile, scrum, ecc.
Se la tua squadra non è abile (come nella tua definizione), non otterrai nulla. In questo caso il processo non ha importanza.
Non abile nel senso di non molta esperienza sarebbe un'altra questione. Se la tua gente ha talento, ma non ha molta esperienza con i progetti, allora un buon processo può aiutare a evitare problemi. I test e le risposte tempestive dei clienti, come previsto da Agile, molto probabilmente eviteranno molti problemi in tale situazione.
Una squadra competente è la cosa più importante.
Un team senza abilità con tutti i processi giusti fallirà. Se non mi credi, porta i tuoi processi di agile / scrum a un reparto diverso (ad esempio, contabilità) e vedi se possono fare un buon software!
Il tuo processo di sviluppo è valido solo come il link più debole , quindi entrambi sono importanti.
Una squadra altrimenti buona che ha un processo disastroso inflitta su di loro, una che soffoca lo sviluppo anziché facilitarla, potrebbe effettivamente finire meno produttiva di una squadra di poveri gli sviluppatori hanno contribuito con un buon processo (ho visto accadere questo).
Nella mia esperienza tuttavia, i buoni sviluppatori tendono a gravitare verso un flusso di lavoro che è più efficiente, se hanno l' autonomia per farlo. Le inefficienze o la burocrazia inutile tendono ad essere imposte dall'alto, quindi un buon manager / team leader può essere fondamentale nel prevenire che i team vengano soffocati dal processo.
Un altro punto è che cambiare una squadra è qualcosa che richiede tempo, mentre cambiare un processo è spesso qualcosa che puoi fare in qualsiasi momento.
In toolware , Tom DeMarco e Timothy Lister parlano molto di come ottenere le squadre di gel , parlando dei team in crescita invece di costruendoli . Diversi processi possono ostacolare i team gelling o possono incoraggiare la crescita del team, quindi questa è una considerazione durante lo sviluppo di un processo.
L'ottimizzazione di un flusso di lavoro può tuttavia essere un processo continuo: problemi o inefficienze nel processo possono essere discussi e risolti man mano che si procede. Se funzionano, puoi guardare ad altri modi per migliorare il tuo processo, altrimenti puoi tornare alla vecchia maniera. Devi solo ricordare che il processo è un mezzo per un fine, non un fine a se stesso .
Sul punto finale, solo tu e il tuo team potete determinare se Scrum o qualsiasi altra metodologia soddisferà le vostre esigenze. Se stai lavorando in un ambiente altrimenti strongmente cascante, l'introduzione di tecniche agili può solo causare attrito con altri team con cui devi interagire. Allo stesso modo, se altri team stanno utilizzando Scrum, potresti scoprire che l'adozione da parte tua può aiutare l'interazione con quei team.
Penso che alle persone manchi un punto qui.
C'è un livello base di competenza che è essenziale nei membri del team - se non si ha quel livello allora sì c'è un problema - tuttavia la domanda diventa quindi ciò che si intende per "esperto", si dovrebbe considerare queste persone adeguatamente competenti come specializzate?
Se l'ambiente ei processi sono buoni, questi sviluppatori competenti consegneranno dove un team di persone più competenti senza processi validi potrebbe non farlo perché non lavoreranno insieme.
Tutti vanno alla ricerca di "rockstars" e "ninja", ma non è ciò che la maggior parte di noi è - i buoni processi riguardano il fatto che tutti noi lavoriamo al meglio delle nostre capacità
Come altri hanno sottolineato, nessuna quantità di processo compenserà completamente una squadra che manca di abilità. Tuttavia, andrà in qualche modo per migliorare le cose. Ad esempio, ma avendo un processo in atto che richiede test da scrivere e i test da superare garantirai che il codice che produci funzioni (in una certa misura).
Tuttavia, un processo cattivo può rovinare gli sforzi degli sviluppatori più esperti se si consente l'uso di scorciatoie e il rilascio di codice non testato (ad esempio). Con questo intendo che se le pressioni da parte della direzione / delle vendite ecc. Costringono gli sviluppatori a eludere le buone pratiche altrimenti il processo è rotto. Un buon processo deve essere quello che la direzione acquista e riconosce e onora.
Competenze e processo sono complementari. Senza uno non puoi produrre codice di qualità.
Solo avere buone pratiche, senza lavoratori qualificati, è simile a 1 milione di scimmie a 1 milione di macchine da scrivere che scrivono tutte le grandi opere ... Ho visto troppe aziende esterne che riproducono le loro [CMM / ITIL / Agile / qualunque] pratica con gli sviluppatori che non potevano codificarsi da un sacchetto di carta figurativo.
La mia risposta è basata su un paio di ipotesi
La paura che un processo troppo rigido impedisca al team di assumere o mantenere sviluppatori altamente qualificati? Avere un processo ostacola la creatività, la flessibilità e la consegna in tempo? E se questo è il caso, è un processo difficile o uno che ha bisogno di un adeguamento?
Un processo strutturato può rendere più facile mantenere in linea gli sviluppatori minori o quelli con la tendenza a essere negligenti. I buoni processi per definizione sono quelli che restituiscono i risultati migliori.
Uno "altamente" abile sviluppatore che non può lavorare all'interno del tuo team o del tuo processo per tutti gli scopi pratici non è esperto. Le persone esperte forniscono risultati nel contesto dei requisiti. Non sono sicuro di quanto sarei disposto a lasciar cadere gli standard per placare alcuni autoproclamati, guru, prima donna, rock star, ninja, tutte le star. Il canottaggio più veloce di chiunque altro nella stessa barca può essere controproducente.
Come persone tecniche, abbiamo la tendenza a giudicare le cose in base al loro valore tecnico. La nostra definizione di "importante" è che il software è creativo, elegante e interessante. La definizione di "importante" di un'azienda è che il software ha un effetto positivo sulle entrate della società. Avere membri del team esperti è più importante per la prima definizione. Avere un buon processo è più importante con la seconda definizione. Tuttavia, uno che è più importante non implica che l'altro sia interamente non importante .
L'intero punto di Agile è che il processo dovrebbe adattarsi rapidamente alle esigenze del business e degli sviluppatori. Se lo stai facendo bene, è generalmente vantaggioso per entrambi, ma ci vuole un po 'di tempo per sistemarsi. Se stai cercando di far rispettare una versione ideologicamente "pura" di agile, avrai problemi.
Cercare di implementare perfettamente un processo è sicuramente la cosa sbagliata a cui mirare. L'obiettivo dovrebbe essere quello di creare un software utile, il processo è semplicemente qualcosa che ti aiuta a raggiungere quell'obiettivo. Se senti che ti sta effettivamente ostacolando, devi cambiarlo (e ogni buona descrizione del processo sottolinea questo punto).
Penso che per avere successo nello sviluppo del software devi avere un team competente e un buon processo. Ma un team competente con un buon processo batterà un team di esperti senza processo (ovviamente i veri esperti non lavorerebbero in questo modo e quasi nessuna azienda ha un intero team di veri esperti). Gli sviluppatori incompetenti senza processo sono il peggiore di tutti i mondi possibili. Quindi, davvero quello che devi confrontare è un buon processo e sviluppatori competenti e un processo difficile e sviluppatori competenti e in questo caso vincerà il buon processo.
Li classificherei in questo modo
Ora il vero problema è nel definire sviluppatori competenti e buoni processi. Un processo formale non è necessariamente buono (vedi cascata) e uno sviluppatore con dieci anni di esperienza non è necessariamente buono.
Scrum può essere un buon processo in un'app legacy, può anche essere un processo negativo, il diavolo è nei dettagli.
Ci sono già molte buone risposte qui, quindi non cercherò di rispondere in modo esauriente alla domanda in tutti i suoi possibili aspetti. Il mio giudizio su questo argomento dipenderebbe piuttosto da quanto siano difficili i problemi che stai cercando di risolvere. È ovvio suppongo; se il tuo problema è sufficientemente avanzato, hai bisogno di programmatori creativi, abili e perspicaci. Il processo non è un sostituto. Ma se la tua dieta di progetto è banale, puoi certamente costruire un ambiente in cui gli sviluppatori senior che hai possono allenare l'inesperto, e puoi usare alcuni processi di sviluppo del software per fornire un quadro di supporto affinché ciò avvenga. Finché hai probabilmente sviluppatori esperti del 50%, dovresti riuscire a far progredire il progetto e sviluppare allo stesso tempo le competenze della tua squadra. Questo presuppone che "esperto" includa alcune abilità di coaching, e ovviamente non è sempre vero.
Certamente dato una scelta vorrei stabilire un piano di abilità relativamente modesto; assumere solo gli sviluppatori che hanno già lavorato con successo sul mantenimento di una base di codice esistente. Macinare software di schifezza è facile. Mantenere una base di codice esistente per un periodo fornisce informazioni importanti su come progettare un buon software.
Leggi altre domande sui tag skills development-process agile quality legacy