L'approccio agile è compatibile con gli appaltatori dello staff?

Molti team lavorano solo con appaltatori agili. Alcune aziende come ThoughtWorks si basano sull'idea di "vendere" team agili. Siamo una squadra di 10 appaltatori che lavorano per una grande telco, tutti della stessa società appaltatrice.

Dove ho visto i problemi era quando c'erano due società di noleggio del corpo nella stessa squadra ... dopo un po 'la squadra è diventata problematica (niente a che fare con agile in ogni caso).

Sì, sicuramente può funzionare. Il trucco è:

a) Struttura corretta della contrattazione - se si paga per il cottimo, gli appaltatori hanno poco interesse a fare molto di più che sbattere le cose insieme per mettere meno ore nel "pezzo"
b) Vendi la tua gestione che non tutti i centesimi pagano direttamente nel prodotto - ci sarà un po 'di formazione / pianificazione / discussione in corso che andrà a buon fine e in definitiva migliorerà il prodotto. Questa è stata la parte più difficile per me.
c) Scegli i giusti appaltatori - tutta la cosa agile inizia a pagare se puoi continuamente assumere lo stesso equipaggio.

In generale, anche io sostengo che questo tipo di scenario è notevolmente aiutato da pratiche agili - se hai persone che vanno e vengono dal team tutto il tempo, essere in grado di controllare, accendere e iniziare la codifica è ancora più importante di altrimenti è.

In risposta alla tua modifica, ci sono diversi gruppi di occhi per guardare la situazione. Quindi, per aiutare a chiarire qualsiasi potenziale confusione, aiuta a capire quali prospettive si applicano.

Dal punto di vista del team di sviluppo, non vi è alcuna differenza tra l'appaltatore e il dipendente. Siamo tutti nella stessa squadra e tutti abbiamo lo stesso obiettivo. Aggiungendo e rimuovendo i membri del team si avrà la stessa interruzione, indipendentemente dal fatto che siano dipendenti o appaltatori. Tutti i membri del team hanno le stesse responsabilità.

Da un punto di vista gestionale, c'è una differenza. L'azienda sta cercando di proteggere la sua risorsa più preziosa: i dipendenti. Per questo motivo, la società preferirà mantenere i suoi dipendenti rispetto ai suoi appaltatori. Se un appaltatore si dimostra inestimabile per la squadra, la società probabilmente tenterà di convertire l'appaltatore in dipendente. Questi tipi di decisioni vivono al di fuori del processo di sviluppo quotidiano.

I processi agili sono più interessati alle attività di sviluppo quotidiane e gestiscono le modalità di consegna di un prodotto di qualità. I processi agili sono meno interessati alle responsabilità di gestione come le decisioni di assunzione / incendio / contratto e più preoccupati di come utilizziamo le risorse a disposizione.

Risposta precedente

Non è una contraddizione fondamentale, ma presenta alcune sfide di allenamento. I processi agili favoriscono un ambiente di mentoring molto naturale. In sostanza, i programmatori dello staff finiscono per essere sempre la voce dell'esperienza, almeno per quanto riguarda la cultura aziendale e le specifiche di come agisce il team.

Avere un regolare flusso e riflusso di programmatori di contratti presenterà le stesse sfide, agile o meno. Devi educare il dipendente a contratto su come si fa business - questo include processi di sviluppo e fatturazione. Devi istruire il programmatore del contratto sul design attuale del sistema in modo che possano iniziare a contribuire il più rapidamente possibile. La speranza è che i dipendenti a contratto sono studi rapidi e possono iniziare a contribuire al progetto molto rapidamente. Il training on-the-job (OJT) funziona abbastanza bene qui.

Ciò che si riduce è che si verificherà un colpo iniziale di produttività quando si assumono nuovi sviluppatori e appaltatori fino a quando non si aggiornano. Più lo fai, più influisce negativamente sulle prestazioni della tua squadra. Hense, il vecchio adagio "Aggiungere più sviluppatori a un progetto già in ritardo lo rende più tardi". (Credo che fosse Fred Brooks, a meno che non stesse citando qualcun altro).

Come appaltatore che si preoccupa molto di Agile e produce software eccellente, posso promettere che ci sono degli appaltatori che non produrranno mai codice di schiaffo se possono aiutarlo e mettono sempre il loro cuore in quello che sono lavorando su.

Il trucco è trovare quegli appaltatori. Cerca le prove che sono preparati ad andare ancora oltre: blog, impegni linguistici, contributi open source, workshop, consigli, ecc. Rivolgiti alla loro precedente esperienza Agile e cerca le prove che amano il loro lavoro. Nel complesso capiamo che siamo assunzioni temporanee, e alcuni di noi in questo modo, utilizzano il nostro tempo tra i contratti per affinare le nostre capacità e ampliare le nostre conoscenze.

Se riesci a trovare davvero grandi appaltatori, miglioreranno la coesione della tua squadra piuttosto che sminuire. Mantienici sul posto per tutta la durata del progetto, poi lasciaci andare mentre il team scende. Faremo una vacanza e saremo in giro per il lancio del prossimo progetto, se hai bisogno di noi.

Hai perfettamente ragione quando hai affermato che i contratti temporanei influenzano negativamente la squadra. In effetti, la velocità è legata a una particolare configurazione di squadra. Qualsiasi nuovo arrivo o partenza invalida il calcolo della velocità che hai effettuato per mesi.

Tuttavia, può funzionare quando gli appaltatori non sono temporanei. Ho lavorato su un progetto in cui il team era costituito da imprenditori con il 95% di uno o due dipendenti. Gli appaltatori erano presenti per 2 o 3 anni fino alla pubblicazione del progetto. Dopo il rilascio, i dipendenti eseguono la manutenzione. Questo modo di lavorare è molto comune.

Per riassumere:

Agile, and especially Scrum will provide all its benefits in a stable team.