Uncovering better ways of developing software
pratiche senza valori
Un post recente sul gruppo di discussione extremeprogramming-it non ha ricevuto per ora troppe risposte. Provo qui cercando maggior fortuna :)
Il post e' stato originato dalla constatazione che in molti casi si applicano metodologie senza condividerne i valori di fondo. Inutile dire che cio' non favorisce i risultati migliori.
Il quesito che trovo interessante e' cosa si puo' fare per cercare di stimolare l'assunzione e la consapevolezza dei valori agili quando in un team non tutti hanno magari la stessa motivazione.
Qualcuno si e' ritrovato nella necessita' di dover "motivare" un team nell'adozione di pratiche agile? Come si e' affrontata la situazione?
Ste
Il post e' stato originato dalla constatazione che in molti casi si applicano metodologie senza condividerne i valori di fondo. Inutile dire che cio' non favorisce i risultati migliori.
Il quesito che trovo interessante e' cosa si puo' fare per cercare di stimolare l'assunzione e la consapevolezza dei valori agili quando in un team non tutti hanno magari la stessa motivazione.
Qualcuno si e' ritrovato nella necessita' di dover "motivare" un team nell'adozione di pratiche agile? Come si e' affrontata la situazione?
Ste
Visualizzazioni: 3
Risposte a questa discussione
-
Permalink Risposto da Luca Minudel su -
il modo migliore che ho visto funzionare è stato mostrare che funziona, nel proprio team, con i propri progetti, affrontando le difficoltà vere di tutti i giorni. a farlo è stato un consulente con anni di esperienza di sviluppo in team agili.
il modo peggiore che ho visto franare è un atteggiamento del tipo "io credo nei metodi agili, chi ci crede e fa quello che dico è bravo, gli altri no" insieme al rifiuto di ogni feedback differente da un "si"
un altro modo che ho visto in particolare per allineare il team su valori comuni è quello di iniziare sul wiki a descrivere cosa ogniuno intende per software di qualità - poi ogni 3 mesi fare un meeting stile open space dove poter discutere ancora su cosa si intende per software di qualità, cosa frena i ns progetti e cosa gli accellera. più di riflessione, raccolta di idee, senza la fase di definire azioni (che cercherebbero di risolvere in un colpo solo cose generiche o troppo grandi, x le azioni meglio le retrospective settimanali o ad ogni iterazione che affrontano subito e in breve tempo singole cose piccole concrete e specifiche utili già per la nuova iterazione che deve cominciare)
linko 3 riferimenti in tema che trovo validi
- http://www.luca.minudel.it/freestaff/situationalleadership.pdf
- http://www.paircoaching.net/docs/LeadershipGame.pdf
- Lean Software Development: An Agile Toolkit - Pagina 103
-
Permalink Risposto da uberto su -
Per mia modesta esperienza ci sono 2 tipi di resistenze ai valori agili:
1) quelle di carattere personale. Persone che (pur essendo bravi programmatori) hanno seri problemi interpersonali e non lavorano bene in team. Per esempio non riescono ad arrivare in ufficio puntuali (e poi lavorano fino alle 8 di sera) o non riescono a fare pair o hanno paura di fare refactoring senza commentare tutto il codice precedente. Qui c'e' poco da fare, pazienza e un po' di aiuto.
2) quelle derivate dalle amare esperienze precedenti. Spesso essere transparenti, sinceri e affidabili non paga nel mondo del lavoro. Molta gente una volta scottata preferisce non correre il rischio di nuovo, qualunque cosa il coach agile possa dire.
Penso che con questa gente l'unica sia mostrare veramente che 1 i valori ci sono sul serio: pe. le persone che tirano fuori i problemi per primi vengono premiate e non castigate. E 2 che cmq non c'e' spazio per fare i furbi o gli imboscati. P.e. se uno nasconde un problema che non sa risolvere fino all'ultimo deve essere severamente ripreso, non perche' non conoscesse la soluzione ma perche' ha cercato di risolverlo da solo invece che affidarsi al team.
-
Permalink Risposto da Dario Santarelli su -
SFOGO:
Quoto 1000 volte "Spesso essere transparenti, sinceri e affidabili non paga nel mondo del lavoro".
Le mie esperienze nel mondo del lavoro sono state quasi tutte traumatiche sotto questo punto di vista. Ah, premetto che non ho MAI visto né fatto parte di un team agile ( = che si ispira anche lontanamente ad una metodologia agile ).
Personalmente comincio a convincermi sempre più di aver fatto parte di team agili senza rendermene conto durante il periodo universitario, in cui ho avuto la possibilità e la fortuna di incontrare persone che anzitutto credono in ciò che fanno, ma soprattutto sono disposte a lavorare in team.
Spero tanto che l'amarezza non mi faccia perdere nella categoria 2).... anche se comincio seriamente a preoccuparmi.
Scusate lo sfogo. Non me ne vogliate.
-
Permalink Risposto da Alberto Brandolini su -
... L'università può mostrare entrambe le facce:
- Non ci sono stipendio o carriera a motivare certe scelte: si può lavorare meglio in gruppo, guidati dall'entusiasmo.
- c'è anche quello che guarda il tuo codice, lo copia e lo mette dentro la sua tesi senza dirtelo (così è grossa il doppio della tua, perchè tu non hai incluso il tuo codice).
Però è sicuramente un ambiente più "vergine" c'è ingenuità, ma non c'è l'"abbiamo sempre fatto così"...
-
Permalink Risposto da Alberto Brandolini su
-
Vero, magari non concordo sul "severamente ripreso", ma il punto è chiaro.
L'elemento di rottura è che si vanno ad intaccare posizioni consolidate "vere o presunte che siano" e determinati ruoli finiscono per essere messi in discussione. Il punto critico è il "programmatore bravo che non sa lavorare in gruppo", ma spesso è "il programmatore insicuro che non vuole lavorare in gruppo".
Credo che un punto che può aiutare tantissimo sia quello di "azzerare il pregresso" e le competenze presunte, mettendo in chiaro che tutti hanno qualcosa da imparare e che l'etichetta (junior, senior, architect, etc.) che ci portiamo dietro non ha grossa importanza (è un po' un casino co i consulenti quando etichetta == tariffa). I casini più grossi li ho visti succedere quando qualcuno affermava "queste cose le so già fare". L'argomento migliore da mettere sul piatto è che le stiamo facendo in un modo nuovo, e che questo sarà per forza di cose la sintesi del contributo di tutti. E che "non sapere" certe cose non è un problema. Il problema è "fare finta di saperle".
Ma questo lo aveva già detto Socrate molto tempo fa.
© 2012 Creato da Marco.
