Il processo Scrum alla fine elimina i membri del team dalle loro rispettive competenze?

Question

La mia organizzazione ha sperimentato l'introduzione di più metodi "Agili". Abbiamo provato l'approccio Scrum per un po 'di tempo e la maggior parte della squadra ha, più o meno, adattato ad esso. Mi piace nel suo insieme, ma sono preoccupato per un impatto potenzialmente grave della metodologia: poiché i team sono costantemente focalizzati sulle funzionalità e sugli elementi del backlog, e i tester sono più integrati con il processo di sviluppo generale, sembra che i set di competenze stiano diventando sfocato, e le persone percepiscono meno rispetto per le loro capacità individuali.

Alcuni dei nostri sviluppatori sono eccellenti nelle tecnologie server-side e nell'ottimizzazione del provisioning dei dati pesanti. Altri hanno investito molte delle loro carriere nell'apprendimento delle tecnologie GUI e hanno sviluppato una comprensione fondamentale degli utenti e dell'usabilità in un'applicazione. Nessuna delle due abilità è migliore dell'altra, ma sono certamente diverse.

È un risultato inevitabile del processo Scrum? Dal momento che tutti nel team (a quanto ho capito) contribuiscono a soddisfare la prossima funzionalità/requisito, l'elemento del backlog o il test dell'obiettivo in questione, la filosofia sottostante sembra essere "chiunque può farlo". Questo, secondo la mia esperienza, semplicemente non è vero. La maggior parte degli ingegneri (sviluppatori, tester, ecc.) Ha un particolare set di abilità che ha affinato nel corso degli anni, e la metodologia Scrum, nella mia mente, tende a svalutare quelle stesse abilità per le quali erano stati precedentemente rispettati.

Ecco un esempio di chiarimenti:

Qualora un repentino cambiamento della tecnologia si verifica sul provisioning dei dati lato server, e ogni elemento della lista delle cose da fare per lo sprint si basa su questo nuovo cambiamento, la GUI gli sviluppatori (che probabilmente non hanno avuto il tempo di abituarsi alla nuova tecnologia) potrebbero non essere in grado di contribuire allo sprint. Per lo meno, avranno bisogno di investire del tempo per essere incrementati, e quindi il loro codice sarà sospetto a causa della loro mancanza di esperienza.

Comprendo la necessità di un rapido sviluppo per scoraggiare i "silos di ruolo", ma ciò non esclude una realtà fondamentale: le persone sviluppano le competenze in base alla necessità, ai loro interessi o alle loro esperienze. Le persone sembrano essere meno motivate quando percepiscono che la loro posizione è "plug-abilità" (ad esempio, possiamo "collegare" chiunque per svolgere questa particolare attività). Come affronta Scrum questo? In caso contrario, qualcuno ha affrontato questo problema adottando la metodologia Scrum?

Answer 1

Il punto di Scrum è che gli sviluppatori si auto-organizzino. Usiamo mischia dove sono io, e i lavori vengono ordinati passivamente dal focus di una persona. Non lo facciamo apposta con un grafico e una lista, succede e basta. Sappiamo tutti chi è il migliore in ciò che, o quali sono i loro obiettivi principali/secondari. Se la persona "principale" ha bisogno di aiuto, ottiene l'aiuto della persona/delle persone con un focus secondario. Riceviamo un sacco di compiti non necessariamente in linea con qualsiasi nostra particolare attenzione, ma tu sai sempre chi chiedere aiuto allora.

Per il tuo esempio: non so che se tu avessi 3 ragazzi server e 5 gui, che ti aspetteresti di fare tutto il lavoro in quello sprint (se i ragazzi del server + qualche aiuto dal altri non era abbastanza). Il modo in cui lo sprint dovrebbe funzionare è che da un elenco prioritario, gli sviluppatori scelgono ciò che pensano di poter fare in quel periodo di 30 giorni.Se ciò significava che i ragazzi della GUI avevano bisogno di 2 giorni di formazione sul lato server per aiutare, questo è quello che vorrebbe dire. A meno che non ci fossero cose concorrenti anche in cima alla lista che potevano fare invece. I compiti di sprint non dovrebbero essere dettati dal management come una scadenza di psuedo.

Se si dispone di un account Safari, c'è un interessante libro per lo studio di casi per lo più di uno dei ragazzi che hanno inventato la mischia.

Answer 2

Suoni come questo porterebbero a sviluppatori più a tutto tondo, e anche consentire a coloro che sono esperti in determinate aree di continuare a contribuire con le loro competenze.

Non ho usato molto me stesso Scrum (ancora), ma dalla tua descrizione, questi tipi di team porterebbero a una squadra/organizzazione che è anche più a tutto tondo - e non dovrebbe essere il obiettivo di qualsiasi squadra?

Answer 3

Se si trova per qualsiasi motivo ("cambio di tecnologia improvviso" o meno) che la quantità di lavoro richiesta per un sistema su uno sprint è maggiore della quantità disponibile, allora c'è un problema con la pianificazione.

Una correzione è che, come suggerite, si prendono i programmatori da altre aree e li si lancia sul mix. Quanto bene funzioni dipende dalle capacità di quella persona e da quanto sia diverso il dominio del problema, ma trattare i programmatori come unità generiche che possono essere estrapolate come necessario non è generalmente una strategia di successo per lo sviluppo di software.

Questo è ancora un problema di programmazione.

Answer 4

Non sono sicuro del perché il set di abilità si offuschi. C'è una buona dose di confusione nel mondo agile. Scrum è un processo di gestione del progetto e non un processo di sviluppo del software e non dovrebbe essere visto come tale. Gli ingegneri devono seguire le proprie metodologie come TDD o programmazione estrema per aggiungere la propria parte all'essere agili.

Niente va via in mischia.

PM continua a leggere i documenti Gli architetti continuano a progettare i propri componenti. L'unica cosa è che ritarda alcune importanti decisioni in un momento più responsabile. Gli sviluppatori devono comunque seguire le best practice come SOLID principles per abilitare il refactoring in modo coerente man mano che cambiano le caratteristiche.

Answer 5

La gestione di modifiche improvvise fa parte di Agile e ciò potrebbe significare che alcune persone devono andare fuori e apprendere nuove competenze. Naturalmente, questo è più all'interno della filosofia Agile generale che in qualsiasi altra specifica Scrum. Potrebbero esserci casi estremi in cui il cliente o l'azienda decidono di cambiare il mondo introducendo qualcosa di nuovo e quindi devono gestire il dolore successivo di quelle persone che aumentano, ma se questo è quello che vogliono e gli sviluppatori sono annullati, allora ci sono solo un paio di scelte: (prendi i tuoi grumi e prova a gestire i principali cambiamenti) o (esci e esci di lì).

Mentre ci possono essere casi in cui qualcuno che si è specializzato in qualcosa può essere in grado di fare le cose più velocemente, questo non significa necessariamente molto se quella è solo una persona nel team che è un esperto e c'è abbastanza lavoro in quella zona per 10 persone per l'intero sprint. Quelli che non sono esperti non dovrebbero semplicemente fare quel lavoro e lasciare che una persona cerchi di passare quanto lui o lei può? Io non la penso così, ma dovrebbe esserci qualcosa da dire per coloro che non sono i migliori in qualcosa che sta ancora cercando di fare ciò che possono fare.

Answer 6

La cosa migliore di Scrum è proprio il fatto che le abilità diventano un po 'sfocate! Il punto è evitare i sili a tutti i costi diffondendo le conoscenze specialistiche all'interno della squadra e lasciando che le persone lavorino un po 'al di fuori della loro zona di comfort.

Ovviamente questo non è per tutti. Alcuni sviluppatori sono felici nel loro ristretto settore specialistico e tali persone sono più di un ostacolo in un processo Scrum che un bene, mentre le persone ben arrotondate e multi talento che sono determinate a svolgere il loro lavoro, di solito si adattano molto bene a e sono molto più produttivi.

Uno dei principali vantaggi di Scrum è quello di coinvolgere l'intero team e investirlo nel progetto, anziché affrontare i propri compiti speciali e poi allontanarsi all'orizzonte. Direi che per la maggior parte delle persone, questo è un modo di lavorare molto più gratificante rispetto al nastro trasportatore - approccio dei processi a cascata.

Quindi consiglierei di abbracciare audacemente la miscelazione delle competenze e di avere persone che si uniscono per risolvere problemi difficili invece di affidarsi a silos specializzati. Il risultato di team composti da persone motivate può essere sorprendente.

Answer 7

penso Scott Ambler risolve questo problema in modo molto approfondito in http://www.agilemodeling.com/essays/generalizingSpecialists.htm ...

Il suo concetto di un Generalizzando specialista è esattamente la cosa proprietà collettiva/Scrum squadra richiede, e rende totale senso per me.

La sua difficile da raggiungere nella vita vera, anche se ;-)

Answer 8

ho lavorato come ScrumMaster per circa 18 mesi e hanno lavorato con due squadre diverse. Inizialmente mi aspettavo di sperimentare i potenziali problemi sollevati, ma non è stato così. Quello che osservo in generale è che il team si evolve in una miscela di specialisti e generalisti, in quanto le persone trovano il ruolo appropriato per se stessi, uno di cui possono godere e avere successo. Questa è l'auto-organizzazione al lavoro. Non ho mai avuto un caso in cui i nostri specialisti erano inattivi.

Se ciò si verifica, mi aspetto che venga sollevato come problema in Sprint Retrospective e il team discuterà su come migliorare la situazione. La conclusione più ovvia (e brutale) sarebbe quella di cambiare la composizione della squadra.

Answer 9

La risposta breve è un enfatico NO! Scrum fa non sfocare o svalutare le competenze richieste per la specializzazione. Scrum non promuove la generalizzazione.

La risposta lunga è che in Scrum, la cosa più importante è ottenere il lavoro "Fatto". La squadra, come squadra (al contrario di una raccolta di singole "stelle") collabora, se necessario, per portare a termine il lavoro. Tutto ciò che serve, tuttavia, lo vogliono (Scrum riguarda i team autogestiti, auto-motivanti, giusto?).

Ciò significa che una squadra di mischia può essere composta da diversi specialisti, i quali fanno principalmente ciò di cui sono specializzati (DBA, Graphic Design, anche tecnici). Il team, nel suo complesso, dovrebbe disporre di tutte le competenze necessarie per soddisfare i requisiti. Questo non equivale a dire che ogni membro della squadra membro deve avere tutte le competenze sopra menzionate.

Detto questo, spesso si desidera, spesso dai membri stessi, che i membri diversi dagli specialisti siano almeno adeguati a in competenze diverse dalla loro specialità. Un altro poster ha già menzionato lo "Specialista generale" di Scott Ambler. Questo aiuta la squadra quando c'è troppo lavoro di un tipo, quando lo specialista è assente, e aiuta il membro quando vorrebbe davvero fare esperienza al di fuori della sua specialità.

Dato che il team si auto-organizza, se per qualche motivo uno specialista si trova nel mezzo dello sprint, senza alcun lavoro da fare nella sua specialità, il modo migliore per affrontarlo è semplicemente chiedere allo specialista cosa vuole fare. Lascia che sia la squadra a decidere.Lo specialista può decidere di aiutare nelle sue altre aree di adeguatezza , fare un POC per il prossimo sprint, "puntellare" le difese fissando un debito tecnico a lungo dimenticato o brillare le scarpe dei membri che sono funzionanti .

Sì. Non so se si tratta di la risposta lunga. Ma è stata sicuramente la risposta lunga a. :-)