Agile è il nuovo microgestione?


80

Questa domanda è stata nella mia testa per un po ', quindi ho voluto chiedere a coloro che stanno seguendo pratiche agili / mischia nei loro ambienti di sviluppo.

La mia azienda si è finalmente avventurata nell'incorporare pratiche agili e ha iniziato con un team di 4 sviluppatori in un gruppo agile su una base di prova. Sono passati 4 mesi con 3 iterazioni e continuano a farlo senza essere completamente agili per il resto di noi. Ciò è dovuto al fatto che la fiducia della direzione è in grado di soddisfare i requisiti aziendali con un po 'di richieste di tipo ad hoc dall'alto.

Di recente, ho parlato con gli sviluppatori che fanno parte di questa iniziativa; mi dicono che non è divertente. Non sono autorizzati a parlare con altri sviluppatori dal loro Scrum Master e non sono autorizzati a rispondere a nessuna telefonata nell'area di lavoro (che forse va bene fino a un certo punto). Ad esempio, se voglio parlare con il mio amico per i calci che fanno parte della squadra agile, non mi è permesso senza l'approvazione del maestro Scrum; che è seduto proprio accanto alla squadra agile.

L'idea di tutto questo o l'agile è di fornire un vuoto completo agli sviluppatori agili da qualsiasi interruzione e di farli impiegare in oltre 6 ore produttive. Bene, ragazzi, non sono un guru agile ma quello che ho letto il documento di lancio agile di Yahoo e simili per altre organizzazioni, mi dà la sensazione che l'agile non sia economico. Richiede risorse e budget per instillare agile nei team e correggere il problema al loro arrivo per rimetterli in carreggiata.

Per i principianti, richiede formazione per sviluppatori e coaching per manager e così via, ecc. L'attuale master Scrum era un manager che ha preso un paio di giorni di agile lezione di formazione pagata dalla direzione e ora guida questo team agile. Ho anche sentito nell'incontro che il manifesto agile non impone che l'agile non sia incastonato e personalizzato in modo diverso per ogni azienda. Bene, tutto suona bene e la ragione.

In conclusione, ho sempre pensato che l'agile avrebbe dovuto portare armonia nei team di sviluppo, risultando in sviluppatori felici. Tuttavia, ho una sensazione molto opposta quando parlo con gli sviluppatori del team agile. Sono scontenti di non poter parlare altro che lavorare, seduti in silenzio tutto il giorno solo lavorando, e sentono che è solo un altro modo per il management di farli lavorare di più.

Dimmi per favore, se questo è uno degli esempi di buone pratiche utilizzate a scopo di vantaggio egoistico per più dollari? O forse, siamo solo noi sviluppatori come me e questo team agile sente che non gli piace lavorare in un ambiente in cui respirano solo perché sono al lavoro.


È un'azienda nel settore sanitario che ha uffici negli Stati Uniti. Sicuramente mi sento come uno stile agile da cowboy che mi rende davvero non voler andare agile, specialmente nella mia attuale compagnia.

Tutto ha a che fare con la gestione essendo completamente economica. Tagliare il caffè costoso per una versione più economica, enfasi sui risparmi ed essere produttivo rimanendo il più magro possibile.

La mia sensazione è che qualcuno nella direzione dietro la porta abbia lanciato questa idea, che l'agile ti faccia produrre di più in modo da poter mostrare ai nostri capi che stiamo producendo di più con lo stesso personale. O, forse, ci permetterà di ridurre il numero di dipendenti in questo caso.

Stanno avendo una riunione giornaliera di 5 minuti. Ma non è permesso chattare o parlare con qualcuno al di fuori della loro squadra. Tutta l'attenzione è rivolta al lavoro.


71
Ho visto più abusi in nome di agili di quelli che mi interessano commentare. Molte volte "stiamo agendo" significa "stiamo gettando via ogni parvenza di processo e facendo ciò che vogliamo, Yeehaw!" (per l'ovvio riferimento da cowboy). Un ambiente tranquillo aiuta sicuramente, ma si hanno per consentire agli sviluppatori di parlare tra loro e martello cose fuori - senza mischia dittatore approvazione.
Berin Loritsch,

28
Bene, non stai facendo Agile ...
CaffGeek

13
Questo è davvero un discorso. Non è una domanda
JohnFx

8
2 giorni nel corso di Scrum Master certificato non rendono il manager un Scrum Master, proprio come 24 ore con Teach + C ++ in 24 ore non ti rendono programmatore c ++ capace. Stanno solo sbagliando.
Matt,

9
lettura obbligatoria: Manifesto Agile Mezzo Arsed "Abbiamo sentito parlare di nuovi modi di sviluppare software pagando consulenti e leggendo i rapporti di Gartner ..."
Gnat,

Risposte:


89

Stai descrivendo la dittatura manageriale, non agile. Agile riguarda lo sviluppo incrementale in un campo di esigenze mutevoli, non di dettare alle persone come vanno individualmente a fare il proprio lavoro.


7
L'unica cosa che riuscivo a trovare era un post "Joel on Software" tra le prime 12 cose che ogni azienda dovrebbe fornire ai propri programmatori. Uno dei 12 era un posto tranquillo dove lavorare. Dubito che Joel Spolsky intendesse questo, comunque.
Berin Loritsch,

5
Un posto di lavoro tranquillo sarebbe quello in cui se non stai conversando, le cose sono generalmente tranquille e dove puoi avere una conversazione senza disturbare gli altri. Ciò significa che nessuna cultura del paging delle persone sul citofono e l'uso di generatori di rumore bianco o altri metodi per ridurre al minimo il livello apparente del suono nelle aree in cui lavorano molte persone. Una regola di non parlare non rende un posto di lavoro tranquillo.
Kevin Cathcart,

5
@Kevin Cathcart, siamo d'accordo violentemente su quello. Ora, sono stato in una società in cui era vero il contrario. Avevamo ~ 40 persone in un bullpen con tavoli aperti e senza cubetti. L'unica squadra che poteva fare qualsiasi cosa era quella che faceva la maggior parte del rumore. Questo è il tipo di ambiente da cui vuoi proteggere.
Berin Loritsch,

8
@Kevin - Il mio dipartimento di sviluppo è una fattoria aperta, proprio accanto a una serie di tre campane con l'etichetta "Vendita", "Grande vendita" e "Grande vendita". Alcune volte al giorno, i venditori suonano quelli e urlano "wooooo!". : - \
Dan Ray

2
@Dan Ho avuto una serie di interviste qualche anno fa in cui tre startup mi hanno detto che dovevano allontanare i venditori dagli sviluppatori perché erano troppo! @ # $ Ing.
Erik Reppen,

46

Non sono autorizzati a parlare con altri sviluppatori dal loro Scrum Master e non sono autorizzati a rispondere a nessuna telefonata nell'area di lavoro

Questo non fa davvero parte delle pratiche Agili - e un problema separato.

Una grande motivazione delle metodologie Agile è una maggiore comunicazione tra gli sviluppatori. La limitazione delle comunicazioni degli sviluppatori <-> è un problema separato dalle pratiche Agile. Non sto dicendo che questo non accada - ovviamente lo è, e viene etichettato come parte del lancio "agile" nella tua organizzazione, ma questo è davvero un problema separato dall'agile (e in qualche modo contro lo spirito dello sviluppo agile, IMO).


29
È assolutamente contrario al primo principio del Manifesto Agile: "Individui e interazioni su processi e strumenti". Vedi agilemanifesto.org per maggiori informazioni.
Berin Loritsch,

"È assolutamente contrario al primissimo principio del <XXX> Manifesto"; sostituisci qualsiasi cosa per XXX e avrai la tua scelta cult. ;-) Scherzi a parte, questo non ti fa meravigliare?
CesarGon,

5
@CesarGon, in questo caso stiamo parlando dei principi di ciò che rende agile il lavoro. Se non riesci ad attribuire ai principi fondamentali dell'agile, allora forse non vuoi agile. Abbastanza semplice. Non sto dicendo "convertiti alla fede", sto dicendo "fai quello che dici di credere". Scherzi a parte, non che non si capisce?
Berin Loritsch,

1
@CesarGon, ciò che l'OP ha descritto riguarda l'opposto polare dell'intenzione di quella linea guida che puoi ottenere. A che punto consideri il tuo tono medio abbastanza vicino? Il modo in cui stai parlando sembra una differenza del 95% tra i toni è abbastanza vicina. Andiamo, forza. E dammi un po 'di credito. Lavoro nel mondo reale e definisco i processi nelle aziende da molto tempo. Capisco abbastanza bene ciò che è abbastanza vicino - e ciò che l'OP ha descritto non lo è.
Berin Loritsch,

2
@Berin Loritsch: ti do credito; non era mia intenzione apparire diversamente. La mia osservazione iniziale sui culti ha provato a sembrare parzialmente scherzosa, in realtà. Il punto che sto cercando di sottolineare è che non abbiamo bisogno di alcune righe su un manifesto per difendere qualcosa che è palesemente contro il buon senso. L'OP descrive una situazione che fa suonare tutti gli allarmi. Spero che lo prenda bene; scusa se sono stato troppo duro. :-)
CesarGon

31

Sembra un'implementazione piuttosto perversa di agile. L'agile, se non altro, dovrebbe ridurre la microgestione, non aumentarla. Il team si impegna e parte del processo è che la direzione confida che il team lo realizzerà. La mischia quotidiana è un modo per gli sviluppatori di comunicare tra loro e un modo per informare di ciò che hanno fatto, non di come hanno trascorso il loro tempo (che è un errore che ho visto in alcuni punti). Anche il processo di stima dovrebbe rimuovere il mantenimento esplicito del tempo dalle stime, dal momento che si dovrebbe stimare la complessità relativa, non il tempo che impiegherà una storia (un altro errore comune). Controllare il tempo impiegato dagli sviluppatori è il segno distintivo della microgestione e rimuovere il tempo dal processo è uno dei principi fondamentali dell'agile.


24

L'ambiente che descrivi suona come una cazzata pseudo-Agile di varietà da giardino .

Mi sono coinvolto con Agile prima che fosse Agile. Intorno al 2000 stavo esaurendo la programmazione, ho sentito parlare della programmazione estrema, l'ho provato e mi è piaciuto. Mi ha dato come sviluppatore un contesto in cui la produzione di software solido era la cosa più importante, e mi ha dato gli strumenti per ridurre al minimo le stronzate che mi stavano facendo impazzire. Lo amavo.

Il problema oggi, che spiego dettagliatamente altrove , è che la maggior parte delle persone che "adottano Agile" in questi giorni non sono interessate a migliorare nulla se ciò li mette a disagio. Quindi, per loro, "Agile" è solo un nuovo bastone per battere gli sviluppatori allo stesso modo. Al contrario, diciamo, un modo per aumentare radicalmente la produttività eliminando tutte le cazzate che rallentano lo sviluppo.

Proprio adesso. Sto fondando una società e userò molti XP, oltre a un sacco di altri trucchi che mi sono appoggiato nel mondo Agile. Ma proprio a causa di storie come la tua, sussulto ogni volta che ho sentito parlare di un'adozione Agile in questi giorni.

Quindi, per rispondere direttamente alla tua domanda: Agile non dovrebbe essere il nuovo microgestione. Dovrebbe essere per dare potere alle persone che fanno il vero lavoro per fare la merda. Ma nel tuo caso, Agile sembra l'ultima bugia che ti stanno dicendo mentre si abbandonano ai loro cattivi istinti. Per cui mi dispiace davvero.


4
+1. Agile / scrum / xp o qualunque cosa siano solo termini "mumbo jumbo" per negozi IT che non sono vere e proprie società di software. Come hai detto, nessuno può fare cambiamenti radicali mentre seppellisce la testa nella sabbia con queste pratiche. Tutto ciò che occorre leggere è questo fantastico sviluppo di software snello: un toolkit agile che lascia dietro di sé tutto il BS. Queste pratiche non sono per i negozi IT è la mia conclusione.
Smith James,

23

Questo non è agile.

Innanzitutto, Scrum non è agile . La mischia, francamente, è una cazzata. Sono cresciuto in una casa di programmazione estrema (letteralmente - ho fatto sedere Kent Beck sul divano di mio padre e parlarmi dei test), e posso dirti subito che Scrum non lo è. Scrum è uno strumento di gestione del progetto, un ritmo definito per un progetto di sviluppo. Ma non ha nulla da dire sullo sviluppo stesso e molto poco da dire su requisiti, pianificazione e relazione con il cliente. XP ha molto da dire al riguardo; qualsiasi altra metodologia che vuole definirsi agile deve avere qualcosa da aggiungere alla conversazione. I sostenitori di Scrum lo hanno descritto non come un processo, ma come un wrapper per un processo. Un uomo saggio una volta ha sottolineato che un involucro è la cosa che rimuovi e scarti per arrivare alle cose buone.

Okay, la mischia è finita!

In secondo luogo, un principio fondante di XP, che credo sia fondamentale per qualsiasi processo agile, è che è centrato sullo sviluppatore . È un modo per dare agli sviluppatori il potere di svolgere il lavoro che sanno di dover svolgere e che sono così frequentemente bloccati. Una squadra agile può essere strutturata come una democrazia o un'autocrazia, ma i leader sono sviluppatori. Ci sono ruoli per i project manager e così via - ruoli vitali - ma non è uno dei team leader. Avere un manager - mi dispiace, "scrum master" - sedersi lì a comandare le persone in giro è un segno sicuro che la squadra non sta agendo.

Sento che dovrebbe esserci un terzo. Non c'è.


-1, non sono d'accordo. Lo sviluppo agile significa anche purificare e facilitare i processi e anche la capacità di adattarsi ai cambiamenti. Che è esattamente ciò di cui parla Scrum. Scrum riguarda anche i requisiti e la pianificazione, in modo diverso.
Falcon,

6
Eh, dai, questo è il 2012. Cita la scrittura pubblica di Kent Beck o lasciala. Non importa se si è flatulato sul tuo divano.
nes1983,

6
@ nes1983: l'ho scritto nel 2011. Le cose erano diverse allora.
Tom Anderson,

3
Non ho mai sentito il termine "debito tecnico" finché la mischia non è apparsa sul mio radar. Sono stato alla formazione. L'olio di serpente facilmente venduto voleva attrarre il management a spese di considerazioni sulla qualità del prodotto a lungo termine. Cazzate al 100%. Anche se lo ingoerei totalmente se Scrum Masters riuscisse a portare una spada in stile Conan per colpire le persone che minacciavano l'integrità del processo.
Erik Reppen,

2
+1 per lo Scrum rant. Penso a Scrum come alla metodologia "Agile" per le persone a cui piace tanto la cascata che vogliono farlo ogni due settimane.
Kyralessa,

16

Scrum è il figlio bastardo di Agile. È lo stile più a cascata di tutte le metodologie agili, ed è per questo che è il più popolare tra i manager.

Tutti i metodi agili riguardano la produzione di codice funzionante senza interferire. Leggi di nuovo. E di nuovo.

Tutto ciò che ostacola tale obiettivo, indipendentemente dalle "regole agili", è negativo. Se le regole si frappongono, cambia le regole f * * ! Questo è il modo agile, questo è ciò che lo rende rilevante ed efficace.

Il miglior esempio di questo è dato da Alistair Cockburn (uno dei creatori del manifesto agile):

“Metti 4-6 persone in una stanza con postazioni di lavoro e lavagne e accesso agli utenti. Invitali a consegnare agli utenti software in esecuzione e testati ogni uno o due mesi, altrimenti lasciali soli.

Se funziona per la qualità dei ragazzi che hai, allora è tutto ciò di cui hai bisogno. Non hai bisogno di uno scrum master o di una metodologia "agile". Se sederti in una mischia quotidiana funziona per te, allora f * * * fallo. Farti alzare è solo una patetica abrogazione della tua capacità di pensare da solo.

C'è una risposta al tipo di agilità che stai facendo. È questo. Stampalo e appuntalo da qualche parte quando non c'è nessun altro e faglielo scoprire da solo.


Hanno intenzione di consegnare agli utenti software in esecuzione e testato, ogni 2/3 settimane, intendi?
user272671

2
@ user272671 NO. Invitali a fornire regolarmente software testato e funzionante all'utente. Non secondo un programma stupidamente arbitrario come 2 o 3 settimane. Se la complessità degli utenti o del software è tale che un ciclo di 6 settimane funziona, allora esegui 6 settimane. Se può essere fatto su un "una volta completato", allora fallo. Non ostacolarti con i vincoli artificiali. Tale non è agile.
gbjbaanb,

11

L'attuale master Scrum era un manager che ha preso un paio di giorni di agile lezione di formazione pagata dalla direzione e ora guida questo team agile.

Questo è il tuo problema. I gestori vogliono un po 'di Agile, non sanno davvero cosa sia e lo impongono ai team. È praticamente cosa fare quando vuoi ridurre significativamente la produttività dei tuoi sviluppatori;)

La nuova proposta di processo dovrebbe provenire dagli sviluppatori. O almeno essere esaminati e approvati da loro se è un'idea del management.

In ogni caso, se gli sviluppatori lo rifiutano, non implementarlo ! O sarà il disastro che descrivi.


9

"Agile" e ogni altra "metodologia di gestione" viene spesso abusata per forzare il microgestione sulle persone. OTOH a volte viene anche abusato per difendere la cattiva fattura.

"Siamo Agili" è la scusa più frequente che sento per mancanza di pianificazione, mancanza di pensiero su design, caratteristiche, qualità, cicli di rilascio. Questo di solito da sviluppatori e gestione inferiore. È follemente anche la scusa più frequentemente usata che ascolto da quadri, architetti, commessi, ecc. Per la micromanagement, le scadenze e gli elenchi delle imprese sempre mutevoli, il forzare gli straordinari del massaggiatore sulle persone (le scadenze e gli elenchi delle imprese sempre mutevoli lo garantiscono ovviamente), ecc. Ecc. Ecc. .

I due ovviamente sono spesso in diretta contraddizione e possono accadere nello stesso progetto.


Nella mia esperienza ... ho sempre e solo sentito parlare di agilità (sempre mischia) per spiegare il microgestione. Non nego, è uno stile diverso e unico di microgestione. Non ho mai sentito uno sviluppatore dire che sono agili e spiegare una breve venuta. Che tipo di scrum forzato gestionale hai vissuto?
JM Becker,

1
ogni volta che ho incontrato la mischia è stata introdotta perché un manager (di solito superiore al project manager) ne aveva sentito parlare come "la cosa".
jwenting

7

Per rispondere alla tua domanda originale, è Agile la nuova micro gestione, direi di no.

Per prima cosa, leggi questo (manifesto Agile) e noterai che non parlare con i tuoi co-sviluppatori non è elencato.

In realtà "Individui e interazioni" è esattamente l'opposto del non parlare con i tuoi co-sviluppatori.


Bene, "Individui e interazioni" sono ciò che stanno facendo in questo momento all'interno della loro squadra. Come va contro il manifesto agile, se guardi dal punto di vista del maestro Scrum? Il problema in questo momento è che non devono avere alcuna interazione con altre squadre in modo da mantenere la loro produttività, che è la causa della lamentela del gruppo agile.
Smith James,

Non stanno interagendo. Questo è il problema. Sicuramente uno sviluppatore può abusare dei privilegi e parlare di cose insignificanti per ore. Tuttavia, la maggior parte dei bravi sviluppatori vuole offrire un progetto di qualità. È una questione di orgoglio. Tutto ciò che lo Scrum Master sta minando, e invece lo rende una questione di repressione. Non è di questo che agile. Un mastro scrum dovrebbe consentire alla squadra di essere produttiva, non sferrare una frusta e dire loro di essere produttiva. Vogliono già essere produttivi.
Berin Loritsch,

2

Agile dovrebbe essere la nuova autogestione. Se l'agile viene praticato correttamente, molte delle decisioni vengono prese da un cliente e uno sviluppatore che lavora una user story con ambito ragionevole che viene aggiunta al backlog quando vengono identificate le attività.

La mischia quotidiana riguarda la comunicazione, non la gestione. Ci saranno alcune discussioni su priorità e bilanciamento del carico, ma la persona gestita nella mischia è, si spera, la scrum master. Come sviluppatore, frequento, dico cosa ho fatto, cosa ho intenzione di fare e di quale aiuto ho bisogno. Quindi il master della mischia dovrebbe entrare in azione eliminando gli ostacoli ai miei progressi.

I team agili non devono pensare che il lavoro quotidiano sia gestito in modo gerarchico. Se le decisioni vengono prese da lontano da qualcuno ai vertici di un'organizzazione gerarchica, è tempo di decentralizzare il processo decisionale! Per alcune persone e alcune organizzazioni, questo potrebbe essere un ponte troppo lontano. Se quanto segue non è vero per la tua organizzazione:

Vivi il Manifesto Agile

"Stiamo scoprendo modi migliori di sviluppare software facendolo e aiutando gli altri a farlo."

Evita "Incontra il nuovo capo, lo stesso del vecchio capo". Originario Agile dall'interno del team il più possibile. A volte questo accade selezionando una coalizione di persone disposte a partecipare a un progetto di prova usando Agile. Se riesci a formare il tuo team Agile da volontari o membri invitati che hanno un track record per un buon lavoro di squadra, possono risolverlo. Usa un piccolo team per un breve progetto, magari per un cliente interno o altamente accessibile.

Abbraccia il cambiamento. Forse puoi prendere un po 'di allenamento, ma forse il tuo budget è limitato e il denaro non è lì. Anche altre opportunità possono fornire miglioramenti. Leggi qualcosa, chiedi ai membri del team di imparare ciò che possono su Agile e di insegnarsi l'un l'altro. Potresti essere in grado di trovare personale nuovo o esistente qualificato per modellare e guidare l'adozione Agile.


1

Le squadre agili sono come squadre di calcio che lavorano per un obiettivo comunemente compreso. Faccio parte di team agili da alcuni anni e la chiave è la comunicazione efficace ed efficiente tra tutti gli stakeholder. Manager / Scrum master sono semplici facilitatori della squadra e la gestione tradizionale / micro gestione ucciderà lo spirito della squadra.

Nelle squadre in cui ho lavorato, siamo incoraggiati a giocare a squadre dopo l'orario di lavoro per migliorare il cameratismo all'interno dei membri. Ho raccolto quei pensieri qui .


1
Sviluppare relazioni di lavoro dopo il lavoro, Dovremmo sviluppare le relazioni di amici e familiari spesso trascurate dopo il lavoro. Considerare che i colleghi di lavoro sono raramente amici e sfruttano la maggior parte delle opportunità per aiutarsi a spese degli altri. La società sì-uomini, compari e strumenti non se ne rendono conto, perché le opportunità sono rare. XP potrebbe avere un certo valore, non ho esperienza per dire diversamente. Scrum è diventata una versione diversa del micromanaging, almeno presso le 3 o giù di lì che le conosco. .... Sai cosa, odio Corporate America troppo per essere anche leggermente obiettivo.
JM Becker,

0

Per rispondere alla tua domanda: No. Agile non è una forma di microgestione. Ma come qualsiasi strumento, le persone possono usarlo in modo errato. Agile è meraviglioso se implementato correttamente e quando le persone sono coerenti con esso.

I miei pensieri sull'argomento "Gli sviluppatori non parlano con nessuno, ma con lo scrum master":

Ho lavorato in un posto dove prima era una regola. TUTTAVIA, la regola era più legata al chiedere alle persone di completare i compiti. Ad esempio, non posso andare a caso a un tester di sviluppo e chiedere loro di fare dei test per me nelle prossime ore. Devo parlare con il maestro della mischia in modo che possano discutere con il loro membro del team su come quel lavoro si adatterà allo sprint se si tratta di un'emergenza (o se deve essere spinto nel backlog per un futuro sprint).

In quel caso, ho capito il concetto di "sviluppatori che non parlano tra loro" perché si è davvero tradotto in attività di canalizzazione attraverso un punto di controllo in modo che un particolare sviluppatore non sia oberato di lavoro o sia così impegnato a svolgere attività di emergenza che non riescono a ottenere i loro piani lavoro fatto.

Altrimenti, gli sviluppatori DOVREBBERO parlarsi. Sempre. Ti aiuta a risolvere i problemi più velocemente, ad avvicinarti come una squadra e a consegnare più velocemente.

Giusto per offrire un'altra prospettiva: sono stato anche in un ambiente in cui la gente pensava che gli sviluppatori "parlassero troppo". Dopo un sit-down, abbiamo scoperto che in realtà tradotto in "gli sviluppatori non sono abbastanza indipendenti da portare a termine il proprio lavoro. Poiché tutto è così frammentato, gli sviluppatori devono rivolgersi ad altre tre persone per completare un piccolo compito".

Quindi, quando i manager hanno deciso di passare all'agile, si aspettavano che ciò contribuisse a portare le informazioni nei posti giusti e a fermare gran parte della frammentazione all'interno dell'organizzazione. Alcune persone erano un po 'deluse dal fatto che dopo l'implementazione di Agile, gli sviluppatori stavano ancora correndo avanti e indietro. Ma quello che non hanno realizzato è che stava succedendo sempre meno. Ci è voluto del tempo però. Quindi, forse se questo è ciò che sta accadendo nella tua organizzazione, potrebbe essere che le persone si aspettassero agili per risolvere le cose durante la notte. Non è così che funziona.


-1

L'autore originale Smith Janes potrebbe aver dato esperienza. Ma questi sono i problemi tipici che ho riscontrato nel progetto Agile.

  1. La maggior parte delle organizzazioni, gli sviluppatori dovrebbero lavorare in più progetti, in Agile / Scrum. Gli Sprint non sono mai considerati questo fatto. il tuo Scrum Master presume che dovresti aver finito con le tue storie alla fine dello sprint .. Il tuo Scrum Master potrebbe essere dedicato a un solo progetto, ma non agli sviluppatori .. QUESTA È LA DISTRAZIONE: non è necessario semplicemente prendere una telefonata o consentire una telefonata.
  2. Ho visto progetti Agile in cui Sprint è pianificato, Storie incluse in Sprint, senza essere rannicchiate ... a metà o metà degli sprint ... gli sviluppatori hanno trovato dipendenze non risolte, requisiti o storia non sono stati completati narrati ..... Questo è uno degli abusi nei progetti più agili.
  3. Test: TTD .. sì, è molto buono .. ma ho visto la maggior parte dei progetti Agile basarsi totalmente sul TTD ... nessun scopo o tempo concesso per test funzionali o umani .. Un altro abuso ... Anche molti Scrum Master non conoscere o comprendere l'importanza del test funzionale. Il tuo codice potrebbe funzionare perfettamente, se non soddisfa le esigenze aziendali .. non serve a nulla .. Ciò accade quando le imprese non partecipano in anticipo .. o la partecipazione è lì ... ma non riflette il processo decisionale aziendale .. Alla fine, gli sviluppatori sono incolpati, non hai fornito la funzionalità ... o finirà con il cambiamento dell'ultimo minuto ... ore extra lunghe perché il tuo Scrum master non vuole prendersi la colpa per la storia non completata.

Abuso qui ... o bassa partecipazione di imprese o partecipanti non completamente informati o uomini d'affari che abbandonano nel mezzo dello sprint.

  1. Non tutti i progetti sono adatti per Agile ... La maggior parte dei gestori o dei maestri della mischia non lo sanno. Progetti di manutenzione. Si potrebbe inizialmente presumere che un difetto possa essere fatto in 8 ore, accettato nello sprint. Dopo aver trascorso 4 ore, ho scoperto che si tratta di Java / di un altro prodotto ... (Di recente ho riscontrato un problema di gestione relativo a Quartz Scheduler ... all'interno del nostro progetto) e questo difetto potrebbe portare a un aggiornamento del prodotto / pacchetto..deal con burocrazia, approvazione, il finanziamento, la nuova versione o l'aggiornamento dovrebbero essere approvati dall'Ingegneria interna ecc., 5.Retrospezione: solo una manciata di progetti Agile fa questo passo .. Se mai fatto..Gestione, Scrum Master non si è mai preso la responsabilità delle storie fallite ..
  2. Accoppiamento ... Molti sviluppatori considerano l'associazione come luogo per abusare dei colleghi ... criticano altri progetti, pratiche di codifica ... considerano il lavoro di gruppo., Imparano gli uni dagli altri ... Un altro modo di abusare di Agile / Scrum.

L'agile è sicuramente una buona metodologia .. A meno che la tua organizzazione non segua completamente o non sia addestrata .... È abusata .... effetti collaterali 60+ ore di lavoro / settimana, colpa, morale basso.


vedi questo link .. perché i progetti Agile falliscono .. brighthubpm.com/agile/55778-why-do-agile-projects-fail
mukunda

Mi capita di concordare con le informazioni presentate in quell'articolo anche lì. Capisco che ci sono quelli che pensano che Agile sia infallibile, ma la realtà è che Agile lascia poco o niente spazio all'introduzione di idee nuove e più efficaci. is..brighthubpm.com / agile / 55778-why-do-agile-projects-fail
user272671

-3

Agile è microgestione sotto mentite spoglie. Non c'è spazio per l'iniziativa o la creatività in Agile, ha rimosso il divertimento dalla programmazione per consentire ai manager incompetenti di mantenere il controllo anche senza avere un indizio dal punto di vista tecnico.


2
Non potresti essere più sbagliato. In agile, i team dovrebbero avere una grande quantità di controllo creativo. Agile richiede un'estrema iniziativa, poiché è il team che decide come implementare ogni storia. La gestione in realtà ha un controllo molto limitato sul processo agile. Personalmente, le tre diverse squadre agili di cui ho fatto parte sono state estremamente divertenti. Sembra che tu abbia sperimentato una grave incompetenza che si è auto identificato come agile senza essere vicino a lui.
Bryan Oakley,

aggiungo un po 'di ragionamento a supporto della tua affermazione (che per me ha un certo senso ma non importa), e rimuoverò il voto negativo
moscerino

1
Sono d'accordo con @Geo. Ad oggi, questa è l'impressione che ho di ciò che "Agile" è, nel mondo reale. Quando hai una tale impostazione sul pavimento della fabbrica, è semplicemente una forma di microgestione. Ora il Manifesto cerca di dirci che non lo è. Ma progetto dopo progetto, sono portato a credere ancora di più che è semplicemente un altro nome per "Micromanagement". E uccide la creatività.
user272671
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.