Scrum trasforma gli sviluppatori attivi in ​​sviluppatori passivi?


103

Sono uno sviluppatore web che lavora in un team di tre sviluppatori e un designer. Sono ormai circa cinque mesi che implementiamo la metodologia di sviluppo del software agile di mischia. Ma ho la strana sensazione che volevo solo condividere in questo sito.

Un fattore importante nella vita umana è il processo decisionale. Tuttavia, c'è una grande differenza nelle decisioni che prendi. Alcune decisioni sono solo il risultato di una forza interna o esterna, mentre altre decisioni sono completamente basate sul tuo libero arbitrio e alcune decisioni sono semplicemente qualcosa nel mezzo. Più libertà hai nel prendere decisioni, più autonomo diventerebbe il tuo lavoro. Questa sembra essere una regola. Perché tendiamo a modellare noi stessi le nostre vite.

C'è una grande differenza tra te che decidi cosa fare o che ti viene detto cosa fare .

Prima della mischia, mi sentivo più libero di prendere le decisioni relative allo sviluppo, all'analisi, alla definizione delle priorità di implementazione, ecc. Avevo più la sensazione di decidere cosa sto facendo .

Tuttavia, a causa della metodologia della mischia, ora molte decisioni vengono semplicemente dal proprietario del prodotto. priorità ai PBI , analizza come dovrebbe funzionare il software, anche a volte come devono essere implementate l'interfaccia utente e le funzionalità. So che questo fa parte della metodologia della mischia e so anche che ciò potrebbe comportare migliori vendite di prodotti in futuro. Tuttavia, ora sento che mi viene sempre detto di fare qualcosa, invece di decidere di fare qualcosa . Questa sindrome ora mi ha reso più passivo verso il lavoro.

  1. Tendo a cercare meno per trovare una soluzione, un approccio o una tecnica migliori
  2. Non mi sveglio la mattina aspettandomi di arrivare a un lavoro piacevole. Piuttosto, mi sento costretto a lavorare per vivere
  3. Ho più fame di lavorare sui miei progetti di hobby dopo il lavoro
  4. Non spingerò più il team a raggiungere i livelli tecnologici più elevati
  5. Adesso passo più tempo a cena o all'ora del tè e ho meno entusiasmo per tornare al lavoro
  6. Ora sono disposto a fare in modo che il lavoro finisca prima, in modo da poter tornare a casa

Il grosso problema è che vedo e diagnostico questo comportamento anche nei miei colleghi. È il risultato della mischia? Scrum fa davvero sentire al team di sviluppo che non ha alcun ruolo nella formazione del software complessivo, rendendo così passivo il progetto? Come posso superare questo sentimento?


4
Sei sicuro che non ti stavi solo impegnando in modo disfunzionale molto prima?
Donal Fellows,

27
Bel post sul blog.
Robert S.

20
quello che stai descrivendo non è

4
@Chad. Ciò di cui ho discusso qui non è una lamentela della mia situazione lavorativa. Mi chiedo solo se questo umore sia il risultato della mischia? E se anche altri sviluppatori stanno sperimentando la stessa cosa o no?
Saeed Neamati,

5
@Saeed - Mi dispiace essere schietto ma il tuo umore è il risultato della tua decisione su come gestire il tuo ambiente di lavoro. Potrebbe essere influenzato anche da altre opinioni e atteggiamenti, ma potresti anche scegliere di abbracciare questo metodo. Ti assolve dalla necessità di essere responsabile delle decisioni di progettazione e ti consente di lavorare solo per risolvere problemi specifici. Non elimina tutta la tua energia e ti consente di lavorare su più progetti a casa. Hai più tempo per svilupparti. Queste non sono cose cattive. Non è il lavoro dei tuoi datori di lavoro renderti felice. Puoi trovare un altro lavoro o puoi accettarlo.
SoylentGray,

Risposte:


51

Tuttavia, ora sento che mi viene sempre detto di fare qualcosa, invece di decidere di fare qualcosa.

Questo è un serio indicatore che qualcosa è andato fuori dai binari. Un progetto agile non dovrebbe sentirsi così. Quella retorica "persone troppo processate" dovrebbe includere "non forziamo la nostra gente a fare cose che fanno schifo". Ecco alcune idee:

Stai facendo "mischia ma"? Cioè, in parte mischia, in parte qualcos'altro. (Vale a dire: "Stiamo facendo la mischia, ma tutte le nostre storie devono provenire dal nostro PMO, non da un product owner.") Un sacco di stronzate pazze si chiama Scrum in questi giorni.

Personalmente, non sei coinvolto nel processo in cui dovresti essere? Ho conosciuto un certo numero di persone arrabbiate per il contenuto delle storie e si scopre che sono coinvolte solo quando la storia è nel backlog dello sprint. Parla con il proprietario del prodotto all'inizio dello sviluppo della storia e ottieni il tuo feedback. (In quanto OP, hanno l'ultima parola, ma ciò non significa che debbano farlo da soli.)

In Scrum, il team dovrebbe essere il proprietario del processo e si prevede che il processo cambierà nel tempo per soddisfare le esigenze del team. Mostra le tue preoccupazioni alla retrospettiva. Se riesci a trovare una modifica del processo da suggerire, questo tende a rendere più facile la vendita per alcune squadre.


10
+1 Scrum (come tutte le metodologie Agili) è più pesante nella conversazione che nella direzione. L'OP dovrebbe descrivere ciò che il risultato finale deve essere in grado di raggiungere, quindi coinvolgere i progettisti e gli sviluppatori sui modi per arrivarci.
StevenV,

5
"people over process": divertente, allora perché imporre il processo SCRUM invece di permettere alle persone di usare il proprio? E perché tutte quelle misure (accoppiare la programmazione, frequenti revisioni dei progressi) che, in nome della trasparenza, consentono di monitorare il lavoro degli sviluppatori molto più da vicino?
Giorgio,

3
@Giorgio: perché lo sviluppo strutturato consente ai team di lavorare insieme senza calpestarsi l'un l'altro per tutto il tempo. Non abbiamo ancora capito come farlo perfettamente.
Phoshi,

2
@Giogio, questo è un problema con l'agile in generale. Sebbene l'obiettivo sia quello di coinvolgere le persone nel processo, in realtà Agile viene seguita religiosamente, il che pone nuovamente il processo sulle persone. Personalmente penso che lean faccia un lavoro migliore di questo agile, sebbene non tenti di imporre una struttura strettamente orizzontale del team, ma consente agli sviluppatori di scegliere meglio i compiti. Supponendo che la tua squadra non cambierà, una scheda kanban in aggiunta a ciò che stai facendo ora potrebbe rendere felice la gestione e anche te felice, dandoti la libertà di scegliere le tue storie / attività.
jQwierdy,

62

Il tuo problema non è Scrum (e come Jarrod Roberson ha menzionato nei commenti, non è Scrum quello che stai descrivendo) - è il microgestione del Product Owner e la tua (e della tua squadra) mancanza di assertività .

"Tuttavia, a causa della metodologia di Scrum, ora molte decisioni vengono semplicemente dal proprietario del prodotto. Dà priorità ai PBI, analizza come dovrebbe funzionare il software, anche a volte come dovrebbero essere implementate l'interfaccia utente e le funzionalità. So che questo fa parte della metodologia di Scrum."

Ti sbagli. Solo da una breve occhiata alla pagina di Wikipedia per Scrum si può vedere che: "il Team, un gruppo interfunzionale che esegue le analisi, la progettazione, l'implementazione, i test, ecc." Vedere? Il Product Owner ti dice cosa fare, ma spetta al Team decidere come farlo.

Sei la persona responsabile dell'implementazione, quindi dovresti decidere come implementare l'applicazione. Ascolta l'opinione del Product Owner, ma la decisione finale spetta a te (o al Team).

BTW microgestione non gira sviluppatori attivi nella sviluppatori passivi.


38
Amen a quest'ultima riga
Wivani,

6
"Il Product Owner ti dice cosa fare, ma sta al Team decidere come farlo." Questo è esattamente ciò che può essere un problema per la motivazione degli sviluppatori: mancanza di innovazione. Il più delle volte i clienti vorranno cavalli più veloci, non automobili. Ma sono assolutamente d'accordo con la microgestione.
MaR

1
+1 @Lukas, a causa della differenziazione tra cosa e come . Grazie compagno.
Saeed Neamati,

5
"Il Product Owner ti dice cosa fare" - Non sono del tutto d'accordo. Dovrebbero dirti di cosa hanno bisogno . Una leggera ma importante differenza. In altre parole: descrivono il problema / problema, tu fornisci la soluzione.
DanMan,

2
@MaR Ecco perché gli sviluppatori non parlano con i clienti. I clienti parlano con il Product Owner e chiedono cavalli più veloci, l'OP è quello che vede tutti i problemi dei clienti, li combina e li dà la priorità, e nel processo scopre che le auto sono migliori dei cavalli più veloci
Izkata,

29

Quello che stai descrivendo NON è SCRUM

Il proprietario del tuo prodotto ha superato i suoi limiti se ti sta dicendo come fare il tuo lavoro tecnicamente, non è affatto quello che riguarda SCRUM.

SCRUM consiste nel liberare gli sviluppatori per concentrarsi sui problemi di sviluppo e responsabilizzarli a determinare il tempo impiegato e le modalità per risolverli .

SCRUM riguarda la collaborazione, ecco a cosa servono gli incontri di pianificazione Sprint, per promuovere la collaborazione tra tutti gli stakeholder; proprietario del prodotto, sviluppatori e test.

Sì, il proprietario del prodotto dovrebbe dare la priorità alle funzionalità, ciò che deve essere consegnato prima in base alle esigenze dei clienti, ma gli sviluppatori dovrebbero fare l'ingegneria e la progettazione, non il proprietario del prodotto.

Non sono d'accordo sul fatto che gli sviluppatori debbano progettare GUI e flussi di lavoro a meno che non siano specificamente incaricati e addestrati a lavorare con i clienti e ne facciano funzionare direttamente la funzionalità. La programmazione della GUI realizzata nel vuoto raramente soddisfa le esigenze dei clienti.

SCRUM consiste nel mettere su un processo leggero che può essere prevedibile e ripetibile rispetto al manifesto agile.

Mi rende triste ascoltare storie secondo cui cose molto buone vengono pervertite in questo modo.


3
La natura umana troverà sempre un modo per strappare la sconfitta dalle fauci della vittoria.
Warren P

2
C'è quello che dovrebbe essere SCRUM , e c'è quello che finisce per essere , almeno nella maggior parte delle aziende. SCRUM non è il male in sé e per sé, ma è uno strumento che è molto facilmente usato per il male dalla direzione.
AresAvatar

11

Immagino prima di Scrum, tutti hanno fatto quello che volevano: yippee ki-yay mf'er . I tuoi utenti sono i tuoi benefattori e guidano la storia e pagano le bollette. Il proprietario del prodotto si assicura che la storia venga completata. In qualche modo, il tuo gruppo è giunto alla conclusione che il Product Owner dovrebbe dirti come programmare.

Vuoi scrivere codice o creare piccole app pulite che ritieni interessanti? "Voglio fare prima la funzione A e non la B, quindi posso mantenere la mia libertà di scelta." Trova un benefattore diverso e non una nuova metodologia di sviluppo.

Sei coinvolto nel titolo del proprietario del progetto o qualcosa del genere. Se hai un motivo valido per non essere d'accordo con la storia, dì qualcosa, fai la tua discussione. Potresti non vincere sempre. È loro compito tornare agli utenti e far loro sapere che esiste un problema valido con la loro richiesta. Ammettiamolo, se la storia ti chiede di rilasciare un database in modo casuale durante il giorno, senza un backup, nessuna perdita di dati o tempi di inattività, hai un problema e un dovere di chiarire la storia.


10

Sembra che le tue avventure in Agile siano state corrotte da Scrum. Trovo che, tra tutte le metodologie agili, Scrum sia la meno agile. È più simile a cascate in miniatura e gestione del progetto aggiuntiva. Questo, ovviamente, lo rende il più apprezzato dai dirigenti che sentono che stanno riprendendo il controllo da quei fastidiosi sviluppatori, ma ovviamente vedi la realtà della situazione.

Agile non si tratta di seguire un percorso prescritto, è progettato per renderti più produttivo e motivato. La gente non elabora dice il manifesto (parafrasato), e questo è perso nel sistema che stai usando.

Quindi cambiarlo. Provalo con la direzione e afferma che si tratta di un passo indietro, che la tua produttività è inferiore rispetto a prima e che non sei soddisfatto del modo in cui funziona. Mostra il Manifesto Agile (e il suo gemello malvagio ) e dimostra che non solo hai imparato le lezioni da questo esperimento, ma vuoi far evolvere i pezzi positivi da esso in un sistema migliore (uno come quello che avevi un tempo, che sembra funzionare bene per te).


6
me? sì, lavoravamo bene, poi il management decise che Agile era il futuro e impose la mischia, il che ci limitò enormemente. Ciò che facevamo senza sforzo si impantanava nel processo e nella burocrazia. Una volta ho preso 3 carte dalla mischia !! Le luci lampeggiarono e le sirene gemettero per questa violazione della "mischia", e una volta presi la carta di nuovo sulla mia scrivania . I poliziotti del project management sono venuti per me. E mi sedevo nella mischia quotidiana, che non andava bene neanche. Tutte le banalità IMHO, ma sono state trasformate in montagne.
gbjbaanb,

2
Non pensi che nel tuo caso sia una cattiva implementazione top-down di Scrum che ha causato una perdita di produttività? Dici di essere "impantanato nel processo e nella burocrazia", ​​il che è strano perché Scrum è la metodologia meno burocratica più semplice del mondo ... In realtà l'intero framework Scrum si inserisce in un foglio o 2. A proposito di ciò che chiami "scrum board" non fa parte del framework. Nel caso di Saeed, anche se credo che il problema sia un divario tra il tipo di organizzazione in cui ha lavorato (con grande libertà e potere decisionale per gli sviluppatori) e il tipo di organizzazione a cui Scrum si applica.
guillaume31,

3
@ianian: sì, quel progetto è stato particolarmente negativo, ma Scrum si rivolge a quel tipo di manager. Dopo tutto, non li vedi mai scegliere Kanban o Crystal. Scrum diventa troppo facilmente "mischia" quando questi ragazzi se ne accorgono. pietà.
gbjbaanb,

1
Penso che sia divertente che qualsiasi compagnia trasformi Scrum in una cerimonia religiosa. Hey! Mettiti in piedi durante questa cerimonia in cui facciamo finta di essere agili! Hey! Sorridi mentre facciamo finta di ascoltarti, e poi continua allegramente a fare ciò che volevamo fare comunque!
Warren P

2
Sono totalmente in disaccordo con la spinta di questa risposta. Penso che una sorta di "mini-cascata" possa essere molto utile, specialmente per gli sviluppatori inesperti ma intelligenti, che sono suscettibili di fare 5 cose diverse contemporaneamente e di non finirne nessuna. In effetti la persona che mi ha insegnato a Scrum ha detto che puoi ancora fare "mini-cascate" in Scrum se vuoi, ma idealmente, dovrebbero durare un periodo di giorni o addirittura ore . Ho pensato, le ore sono troppo brevi. Non puoi sempre progettare-> implementare-> testare una storia in poche ore. E dividere le storie in modo che tu non sia sempre ottimale.
Robin Green

8

Penso che semplicemente voi ragazzi siete abituati ad avere più proprietà - e tutti quelli che penso preferiscono, la sua natura umana.

Sfortunatamente penso che molto software sia inferiore a quello che potrebbe essere, perché spesso le parti sono scritte per lo sviluppatore e non per il client. Il tuo nuovo approccio dovrebbe ridurlo, ma a scapito del sentimento di proprietà.

Non ho idea di come suggerirti di rendere le cose migliori o più divertenti, ma è un'ottima domanda e un'ottima intuizione.


100% d'accordo. Ora sei più allineato con il proprietario del prodotto, ma ciò significa che hai meno libertà di fare ciò che ritieni giusto. Anche questo l'ho sperimentato, mi ha fatto schifo e ha reso il mio lavoro molto meno piacevole. Ciò significava che ero molto più in linea con gli obiettivi dell'azienda e del product manager. Gli affari pagano le bollette - compreso il mio stipendio - quindi sì, possono dire quello che vogliono a livello di dettaglio. Non penso che ti stiano effettivamente dicendo come programmare. Se sapessero come possono farlo da soli.
Michael Durrant,

L'azienda non paga gli sviluppatori per fare ciò che vogliono. Pagano gli sviluppatori per il guadagno di produttività fornito da un buon ambiente software. Se lasci che l'attività ti dica cosa fare "a livello di dettaglio", pensi davvero che otterranno il buon ambiente software che stanno cercando?
Andomar,

@Andomar - È un equilibrio. Ogni parte ha i suoi ideali, ipotesi e difetti. Ignorare uno di questi porta al pericolo.
Jonno,

5

Stai ottenendo le storie degli utenti sotto forma di "Come - ruolo--, voglio --goal / desiderio-- in modo che - benefici--"? Sembra che il tuo Product Owner voglia fare il lavoro di progettazione e potrebbe non essere la persona migliore per farlo. L'uso del modello di storie utente può aiutare a garantire che il Product Owner sia fedele all'interesse commerciale e che gli sviluppatori software stiano realizzando lo sviluppo del software.


4
Come sviluppatore non voglio più rivedere questo tipo di user story, quindi non dovrò mai lamentarmi interiormente della sua follia.
Warren P

@WarrenP Sì, la caldaia può essere una seccatura, sia che si tratti di codice della caldaia o requisiti della caldaia. Penso che il punto chiave sia che tutti e 3 questi elementi debbano essere dichiarati o compresi, ma, cosa ancora più importante, dovrebbe essere chiaro a tutti ciò che è realmente desiderato, e i requisiti di modello con la caldaia possono effettivamente ostacolarlo. Soprattutto se gli sviluppatori iniziano a pensare che inserire poche parole in quel modello sia sempre sufficiente.
Robin Green

4

In Scrum c'è molto spazio per gli sviluppatori per contribuire e dare consigli su nuove funzionalità, interfaccia utente, usabilità ... Scrum richiede collaborazione e conversazione tra uomini d'affari e sviluppatori e ciò lo consente. Tuttavia, alla fine, il proprietario del prodotto avrà sempre l'ultima parola perché è lui il responsabile della massimizzazione del valore commerciale degli incrementi del software prodotti dopo lo sprint (in altre parole, il ROI).

Dal manifesto agile:

La nostra massima priorità è soddisfare il cliente attraverso la consegna anticipata e continua di software prezioso.

Tuttavia, il proprietario del prodotto che spiega come implementare l'interfaccia utente e le funzionalità non è accettabile. In questo caso si dovrebbe avere l'ultima parola in quanto v'è responsabile per la qualità interna del software si produce.

Forse lavori in un'azienda creata da sviluppatori in cui i programmatori avevano la libertà di implementare qualsiasi funzione desiderassero. Tuttavia, la maggior parte delle metodologie Agili fa una chiara separazione tra le persone del dominio aziendale e il team responsabile della produzione di software (sviluppatori, tester ...) che è la divisione di lavoro più comune nella maggior parte dei luoghi. Se i miei presupposti sono giusti, posso capire la sensazione che hai di non essere più in grado di "avere un'influenza sul quadro generale" ma con la crescita dell'azienda credo che sarebbe stato comunque il caso, Scrum o no.

Per quanto riguarda l'analisi, la progettazione e altre attività di meta-sviluppo menzionate (che di nuovo non dovrebbero essere svolte dal proprietario del prodotto), i team Agile dovrebbero essere interfunzionali e privi di silos. Nessuno dovrebbe possedere tutte le conoscenze relative a una specifica attività di sviluppo, quindi forse c'è un'opportunità per te di diversificare lì rispetto al "codice di scimmia".


3

Al contrario, ho scoperto che fare in modo che un proprietario del prodotto prenda decisioni sulla funzionalità mi consente di dedicare più tempo alla produzione del codice di qualità. Inoltre, se ci sono dubbi validi, posso sempre mettere in discussione le decisioni dei proprietari dei prodotti e questo di solito porta a discussioni fruttuose.


3

Qui pratichiamo Scrum. Abbiamo una riunione di pianificazione quindicinale in cui nutriamo le attuali priorità aziendali, i successi e i fallimenti dello sprint precedente e decidiamo, come squadra , cosa vogliamo affrontare per lo sprint successivo.

Uno dei modi in cui lo facciamo è ordinare l'arretrato su una scheda in base alla complessità in verticale e alla priorità aziendale in senso orizzontale. Successivamente, il Product Owner ha avuto il suo contributo, quindi spetta al team scegliere cosa vogliamo fare. Ovviamente, scegliere un compito a bassa priorità e ad alta complessità è disapprovato, ma lo stiamo decidendo come una squadra. Rende più lunghe le sessioni di pianificazione, ma ne vale la pena e una parte fondamentale del processo Agile.

E a volte abbiamo una micro-gestione, ma questo è un problema diverso.


3

Il vero problema che stai descrivendo è una patologia comune quando i team adottano una metodologia: spengono il cervello. Questo è vero sia con un sistema agile di nuova scuola che con sistemi pesanti della vecchia scuola.

D: La metodologia prescrive x, ma x non funziona bene. Cosa dovremmo fare?

A: Affina la tua implementazione di x. Forse smetti di farlo del tutto. La metodologia non è il tuo capo!

In questo caso specifico, sembra che il proprietario del prodotto stia facendo troppo. Ti senti a tuo agio a parlargli? Ti sentiresti a tuo agio con quella conversazione se non "facessi la mischia"? Se il proprietario del prodotto non è sensibile al feedback costruttivo, non è un problema di metodologia, è un problema con il proprietario del prodotto.


2

Non sono davvero in sintonia con l'intera faccenda della mischia perché sono stato più cascata per un po '.

Ad essere onesti, questo sembra più un problema di gestione del personale che un problema di tecnica di gestione del progetto. Come in è più basato sulle persone che sulla tecnica.


No @temptar, la nostra relazione è davvero buona. Senza offesa, senza odio, niente di niente. Va tutto bene, tutto tranne ciò che proviamo per il lavoro.
Saeed Neamati,

2

Il ruolo dei leader in un team auto-organizzante sarebbe un post sul blog su qualcosa che sembra mancare nel tuo post. Dov'è il team che decide quale lavoro viene svolto in uno sprint? Dov'è la squadra che ha la proprietà nel processo e nel lavoro? Hai qualcuno che conosce Scrum abbastanza da farlo Scrum e non una versione perversa di esso?


2

Ho avuto la stessa esperienza con Scrum e mi piace definirla la "tirannia della storia".

Dalla mia esperienza, gli sviluppatori più dal punto di vista creativo / design / frontend sembrano soffrirne di più rispetto alle persone coinvolte nel lavoro di backend.

L'unica via d'uscita che ho trovato finora è stata quella di abbandonare Scrum - spesso non possibile e / o appropriato perché dopo tutto ha i suoi vantaggi - o introdurre qualcosa come il 20% di tempo di Google per offrire agli sviluppatori uno sbocco creativo oltre al "tu" sei libero di scegliere come implementare la pagina di accesso ", perché in realtà non lo sei poiché l'implementazione è limitata dal codice e dall'architettura di sistema esistenti, vale a dire se non si considera la libertà di scegliere tra" a for e a while loop "a la libertà.


1

C'è una grande differenza tra te che decidi cosa fare o che ti viene detto cosa fare .

Nella mia esperienza, c'è solo un tempo piuttosto lungo modo da sentirsi dire cosa fare per decidere cosa fare.

Alla fine di questo modo di solito scopre che ci sono stati istruiti non perché li come l'energia e non perché li hanno niente di meglio da fare. Al contrario, alla fine di questo modo - quando si guadagnano sufficiente fiducia nella nostra squadra - sembrano essere sollevato e felicemente ci ha passare il maggior controllo siamo in grado di gestire (e se la loro fiducia è veramente duro, hanno anche cercare di passare più di quello)

Oh, e nella mia esperienza questo non ha praticamente nulla a che fare con Scrum / agile. Accaduto con mischia, iterativo, cascata, qualunque cosa. Sembra che la questione della fiducia sia il processo agnostico


1

Nel nostro team, il product owner ci dice cosa fare e decidiamo come lo facciamo. È davvero importante avere questa separazione o finirai nella situazione che hai descritto.


1

Secondo la mia esperienza, Scrum è di osservarti profondamente ciò che fai. È solo seduto sulla tua spalla e guarda cosa fai. Anche se ha il suo vantaggio, odio la metodologia della mischia. Si aspetta il conteggio, non la qualità. La qualità viene compromessa dalla metodologia di Scrum.


"La qualità sta venendo compromessa con la metodologia della mischia.": Forse è un po 'estremo dire che la qualità viene compromessa ma, sì, la controllabilità del progetto ha una priorità più alta della qualità.
Giorgio,

Incredibile quanto poco alcune persone sappiano della mischia o dell'agile, eppure come postano come le autorità. Si ha l'impressione che un individuo abbia lavorato per alcune settimane in un gruppo disfunzionale in cui ha affermato di "fare la mischia" e ha concluso che si suppone che dovrebbe essere la mischia. In questo caso, è un ragazzo completamente anonimo con un solo post o commento in 4 anni e nessuna prova di esperienza in materia. Questo è il motivo per cui non possiamo prendere molto sul serio molti di questi commenti.
Curtis Reed,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.