Come comportarsi con un capo squadra che non ama la programmazione estrema?

1. Tecnicamente, ci sono 3 casi qui. Potrebbe aumentare il tempo. Potrebbe non esserlo e potrebbe non avere alcun effetto. Non sto cercando di essere irriverente, ma questa è una condizione inamovibile. Ci sono casi in cui il passaggio a un metodo Agile ha salvato il progetto. Allo stesso modo, ci sono casi in cui quel passaggio ha ucciso il progetto. Ci sono troppe variabili coinvolte per fare generalità al livello che stiamo discutendo. Una valutazione deve essere fatta da coloro che conoscono meglio il loro attuale processo e valutano se l'XP (o qualsiasi altra metodologia) è un buon compromesso.

2. Questo è vero se attualmente non stai usando XP. Ma questo è vero per qualsiasi nuova metodologia. Ci sono costi di avvio associati alla modifica della metodologia di sviluppo. I dipendenti devono essere formati; la gestione deve essere convinta; gli utensili devono essere modificati; ecc ... XP non è una soluzione magica che rinuncia ai costi di transizione.

3. Per introversi, questo è molto vero. La programmazione di coppie tramite XP è non per tutti.

4. I test unitari sono duri, punto. Ci vuole un impegno da parte dell'organizzazione per creare e mantenerli. Anche in questo caso, XP non è una soluzione magica.

Non importa quale sia la prova - il tuo team leader ha preso una decisione. Costringere uno scontro e rinunciare a studi pubblicati intorno non farà altro che frustrare sia te che lui.

Se sei impegnato a sfruttare i vantaggi di XP, allora devi iniziare ad adottare i metodi che puoi nel tuo lavoro. Quando inizi a fornire elementi di lavoro di qualità superiore più velocemente rispetto ai tuoi colleghi, il tuo team lead potrebbe ascoltare.

Vale anche la pena di notare che XP potrebbe essere controindicato per alcune industrie. Il lavoro nel settore della difesa, ad esempio, è molto documentato / artefatto pesante a causa dei contratti e delle parti coinvolte. XP e altri metodi Agile tendono ad essere più leggeri nella documentazione e quindi non sono appropriati. Allo stesso modo, i progetti che vengono esternalizzati non si adattano bene al modello Agile poiché l'interazione richiesta per la raccolta e la verifica dei requisiti non è altrettanto facile da realizzare.

Non sto cercando di colpire XP, ha il suo valore. Ma è uno strumento e devi sapere quando è appropriato usare quello strumento o no.

Con metodologie come XP e Agile, avrai sempre zeloti su entrambi i lati, a favore e contro.

Con alcune persone contrarie, puoi mai cambiare idea.

Quindi, prima di tutto, penso attentamente a questo e valuto realisticamente se pensi che questa persona possa mai essere convinta.

Alcune battaglie non valgono la pena di combattere. Soprattutto se sei per mancanza di una frase migliore "solo uno sviluppatore", cambiare l'intero processo di sviluppo del software potrebbe essere al di fuori delle tue competenze.

Invece, potresti optare per le cose facili che potrebbero aiutare il tuo team di sviluppo, scegliere e scegliere parti di XP che ti piacciono e provare a introdurle, invece di provare a modificare l'intera metodologia.

Se continui a cercare di convincerlo, assicurati di avere fatti ben documentati che rispecchino / confutino ciascuna delle sue preoccupazioni. Mostra che alcune delle sue preoccupazioni si verificano effettivamente usando la tua attuale metodologia.

Non conosco alcuna prova che provi gli effetti negativi della programmazione estrema che sarebbe utile per i team XP in generale. E dimostrarli correttamente potrebbe non essere l'approccio più efficace per influenzare il cambiamento.

È qualcosa che solo l'esperienza e la sperimentazione possono dimostrare l'efficacia di XP per il team nel suo complesso.

Il team leader sembra essere comprensibilmente preoccupato per l'influenza di XP sulla "velocità". Dai un'occhiata a Scrum (anche Scrum Guide è un'ottima introduzione). Scrum si concentra sul processo di sviluppo del prodotto suddividendolo in blocchi gestibili di incremento del prodotto (chiamati Sprint). Questo potrebbe essere usato per prendere pratiche XP / Agile (test unitario, programmazione coppia) e dimostrare ai lead / management del team che è possibile mantenere la velocità pur ottenendo incrementi nel prodotto. Fornirebbe nel tempo prove che il tuo team impiegherà meno tempo a sistemare bug di stile di regressione e più tempo per le funzionalità dei clienti.