Come pensi che dovremmo gestire 1 collaboratore esterno / sviluppatore nell'ambito del metodo scrum?
Ad esempio: dovremmo isolare le attività che deve eseguire?
Come pensi che dovremmo gestire 1 collaboratore esterno / sviluppatore nell'ambito del metodo scrum?
Ad esempio: dovremmo isolare le attività che deve eseguire?
Se la squadra di mischia è matura, è una questione che devono decidere. L'obiettivo sarebbe quello di fare tutto il meglio per aiutare la squadra a raggiungere i propri obiettivi. Ricorda: non ci sono punti bonus per attenersi a una metodologia, anche alla mischia. Il punto # 1 del manifesto agile è "Individui e interazioni su processi e strumenti".
Senza conoscere ulteriori dettagli, penso che dovresti trattare questa persona come una parte normale del team. Devono essere coinvolti nella situazione quotidiana, e devono chiamare a pianificare sprint, dimostrazioni e retrospettive. Idealmente, dovresti impostare un canale di comunicazione di ordinamento in modo che possano essere parte delle discussioni quando possibile (ad esempio: slack ). Questo può fornire sfide se si trovano in un fuso orario molto diverso, ma dovrebbe essere possibile regolare la pianificazione di tutti per avere almeno un po 'di tempo che si sovrappone.
Per quanto riguarda l'isolamento delle attività, direi che non dovresti fare nulla di speciale. Il team probabilmente capirà cosa funziona meglio per la squadra e farlo. Se ciò che hanno scelto (ad esempio: isolare le attività o non isolare le attività) non funziona, la retrospettiva è una buona opportunità per risolverlo.
1. Punto di vista metodologico
Dal punto di vista metodologico, uno sviluppatore esterno è solo un membro del team come qualsiasi altro. Maneggiarlo e isolarlo renderà la squadra meno efficace.
2. Vincoli legali
Dal punto di vista legale, dipende dalla tua giurisdizione. Nella maggior parte dei paesi europei, ad esempio, la gestione di un appaltatore esterno come se fosse il proprio personale è strettamente illegale (anche se nel settore IT questo è abbastanza comune).
Queste leggi restrittive sono state adottate nel secolo scorso al fine di evitare che i datori di lavoro aggirassero gli accordi con il sindacato prestando personale da altre società meno tutelate. Naturalmente, nel mondo IT, dove i consulenti o gli sviluppatori contratti sono spesso più costosi del proprio personale e hanno migliori condizioni di lavoro, questo sembra assurdo. Ma le vecchie leggi si applicano ancora.
In base a questo principio, i subappaltatori dovrebbero subappaltare: devono svolgere compiti indipendenti ben identificati. L'elemento chiave è che agiscono in modo indipendente e non su ordini del proprio personale.
Fortunatamente, in una squadra di mischia, non esiste una vera subordinazione, ogni membro del team contribuisce con le sue opinioni e la sua parte di lavoro. Quindi torniamo al punto 1 :-)
Dichiarazione di non responsabilità: questo non è un consiglio legale. È solo un'opinione personale di un professionista IT basato sulla sua esperienza professionale. Per consulenza legale, consultare un avvocato o un esperto legale qualificato nella propria giurisdizione
In primo luogo, i consulenti devono essere strettamente gestiti. Gli obiettivi di un consulente sono non gli obiettivi della tua organizzazione e avere accordi chiari su ciò su cui lavorare è prezioso. Puoi usare scrum, chiamate Skype settimanali, un piano di progetto o anche solo una lista di controllo. Il problema chiave è non trovarsi mai in un caso in cui non si capisce su quale attività il consulente sta lavorando.
Detto questo, anche un contraente all'interno della tua mischia è generalmente soddisfacente finché finisci con la comprensione di ciò che lui o lei farà e questo è ciò che vuoi fare. Se il risultato tende a "ristrutturare questo codice senza benefici immediati" o peggio "ristrutturare questo codice per utilizzare un nuovo framework che potrebbe aiutare nel mio prossimo concerto di consulenza perché tutti i ragazzi sono bravi", è necessario dettare più di quanto consentito indipendenza.
Se ritieni di aver perso il controllo di un appaltatore, perdi l'appaltatore. Cercare di riportarli indietro non finisce mai bene.
Leggi altre domande sui tag scrum