Agile obbliga gli sviluppatori a dedicare più tempo a lavorare effettivamente?

Osservando le pratiche Agile comuni, mi sembra che (intenzionalmente o non intenzionalmente?) Costringano gli sviluppatori a trascorrere più tempo effettivamente a lavorare invece di leggere blog / articoli, chat, pause caffè e semplicemente procrastinare.

In particolare:

1) Accoppia la programmazione - il più grande sostenitore del lavoro, solo perché è scomodo fare tutta quella procrastinazione quando ci sono due di voi seduti insieme.

2) Racconti: quando hai un enorme pezzo di lavoro che deve essere fatto ad esempio in un mese, è abbastanza comune rilassarsi nelle prime tre settimane e passare alla modalità SCADENZA OMG per l'ultima.

E con i piccoli pezzi (che devono essere fatti in un giorno o meno) è esattamente l'opposto: senti che il tempo è stretto, non c'è spazio per le manovre e sarai ritenuto responsabile per l'attività abbastanza presto, quindi inizi lavorando immediatamente.

3) Comunicazione di squadra e coesione - quando si sottoperformano in un ambiente lento, distanziato e silenzioso, può sembrare ok, ma quando alla fine della giornata allo Scrum meeting tutti vantano ciò che hanno realizzato e non hai nulla da dire che potresti davvero sentire si vergogna.

4) Test e feedback - ancora una volta, ti impedisce di mantenere le attività "99% pronte" (quando in realtà è circa il 20%) fino a quando la scadenza non si verifica improvvisamente.

Ritieni che in Agile lavori più che in metodologie "convenzionali"? Questa pressione è compensata dall'ambiente più confortevole e dalla sensazione di fare rapidamente le cose giuste?

L'idea principale dietro i metodi agili è di aiutarti a essere produttivo, in senso positivo. A nessuno importa se passi un'ora a navigare ogni giorno se rispetti la scadenza. Tutti si arrabbiano se navighi mezz'ora ogni giorno ma non rispetti la scadenza. La soluzione: semplificare il rispetto della scadenza.

Come hai notato, la programmazione delle coppie ti assicura di rimanere concentrato (tra tutti gli altri vantaggi come migliorare la diffusione di abilità / conoscenza, codice migliore, meno bug, design uniforme, ecc.).

Ho scoperto che la disciplina è sempre una lotta per me. Se mi associo a qualcuno, è probabile che uno di noi voglia un po 'di lavoro oggi e tira l'altro. Quindi il "lavoro per un mese" si trasforma spesso in "lavorare insieme per una settimana", sorpreso dal fatto che quell'enorme quantità di lavoro si sia risolta alla fine, trascorrendo un giorno circa di recupero (refactoring, sistemando TODO nel codice, aggiungendo un un paio di prove, navigare con la coscienza pulita) e poi afferrare il mese successivo di lavoro.

Risultato netto: sono molto più rilassato (più perché che nonostante la costante supervisione), la coesione del team è molto migliore, il lavoro viene svolto più rapidamente, le persone non si aggirano su problemi minori per ore o addirittura giorni (perché qualcun altro può individuare il problema molto più velocemente).

Quando dici "potresti davvero vergognarti", non è una buona cosa? Significa che senti di aver sbagliato e dovresti. Non vieni pagato per non fare nulla. Non fare nulla ti fa sentire indifeso, infelice, indegno, infelice. Invece di vergognarti, stai indietro e pensa "Perché non ho realizzato nulla oggi?" Hai bisogno di aiuto? C'è qualcosa che non capisci? Il compito attuale è troppo difficile? Non ti piace? Forse puoi cambiare compito con qualcun altro. Forse qualcun altro può aiutarti a superare. Agile significa: assumere la responsabilità invece di essere micro-gestito come un burattino sulle corde. Ti serve uno strumento? Vai dal tuo capo e chiedilo. Impara a discutere. Impara a rialzarti e urlare quando devi.

Per quanto riguarda i test, c'è un punto debole quando il tuo codice crolla improvvisamente da "bello" a "perfetto". Questo è il momento in cui noti che devi implementare la funzione X e hai pensato che sarebbe stato un incubo e improvvisamente ti rendi conto che il codice è quasi arrivato. Solo un piccolo refactoring qua e là. Una nuova classe e fatto. Quattro settimane di lavoro sono diventate improvvisamente un giorno. Vittoria! Trionfo!

Sono d'accordo.

Coppia di programmazione

È un modo molto intenso ed esauriente di lavorare e non lo applico mai a meno che non abbia alcuni sviluppatori che devono essere allenati da altri (nuovi arrivati, ad esempio)

Storie brevi

Comunicazione di squadra e coesione

Test e feedback

Sì Agile e in particolare Scrum è un enorme incentivo alla produttività. Se applicato correttamente, il turn over può arrivare fino al 20% (1 sviluppatore su 5 lascia l'azienda).

Il motivo è semplice: Scrum non fornisce più produttività it provides the whole company with much more visibility on what's going on(anche nella gestione ovviamente).

• È impossibile per uno sviluppatore fare solo il minimo indispensabile. Il minium nudo è ora la media della squadra!

• È impossibile per la direzione non collaborare correttamente.

Questo è il motivo per cui ho detto (nelle mie altre risposte in domande simili), che Agile NON è per ogni organizzazione (e per tutti).

Ad esempio, il settore pubblico non è davvero adatto per Agile.

Agile viene utilizzato come strumento di pressione? Certo, l'ho visto molte volte. Non fa che peggiorare le cose.

Ritieni che in Agile lavori più che in metodologie "convenzionali"? Questa pressione è compensata dall'ambiente più confortevole e dalla sensazione di fare rapidamente le cose giuste?

Mi fa lavorare di più, ma soprattutto mi fa lavorare sulla cosa giusta. In ogni momento so cosa dovrei fare .

È una specie di pressione positiva. Questo è abbastanza diverso da alcuni esterni "sei già in ritardo rispetto al programma, lavora di più, codice straordinario!" tipo di pressione.

In realtà, sono molto più produttivo quando utilizzo i metodi convenzionali. Con il metodo convenzionale, creo ad esempio un'analisi dettagliata dei requisiti, uno studio di fattibilità, una specifica funzionale, una specifica tecnica e molti protocolli di riunione, il tutto in pochi mesi! Potrei persino creare alcune righe di codice una volta terminata l'analisi dell'impatto!

Agile, tutto ciò che creo sono alcuni risultati.

Nella nostra azienda,

Programmazione di coppia - Quando qualcosa di veramente complesso e richiede un'analisi approfondita, anche metteremmo insieme due persone eccellenti e completeremmo il compito in tempi VELOCI. Qui la complessità dell'attività decide la necessità della programmazione di coppia.

Racconti brevi - Quindi rilassarmi per 3 settimane (circa 5-6 ore al giorno) e correre all'ultimo momento (circa 12-14 ore al giorno) come sviluppatore non mi piace avere un'oscillazione nel mio carico di lavoro. Lavora per circa 8 ore al giorno e mantieni il tuo programma stabile e questo sembra sempre COOL.

Comunicazione di squadra e coesione - Nella riunione della mischia non solo condividiamo lo stato dell'attività ma anche gli ostacoli. Qui, quando qualcuno ha davvero bisogno di aiuto, gli altri membri escogitano le loro idee per aiutarlo. Ma sicuramente hai bisogno di un team eccellente per questo e siamo :)

Test e feedback - Sicuramente come sviluppatore non voglio che io stesso sia caricato con i bug, il momento successivo dopo aver trovato un bug è stato quello di risolverlo e di nuovo, questo mi permetterebbe di avere una buona previsione di ciò che dovrebbe / può essere fatto successivamente e riprogrammare la scadenza (se necessario) di conseguenza.

Quindi, come sviluppatore, sono molto contento del tipo di attività che prendo e dannatamente sicuro di poter dire che non ho mai sentito la VERA pressione della scadenza.

Ritieni che in Agile lavori più che in metodologie "convenzionali"?

• Se vuoi dire che mi sento più produttivo sotto Agile, direi che dipende .
   
  _{Di solito ci penso in termini di Ferrari (come convenzionale) vs Landrover (come Scrum). Quando si guida su un'autostrada, la Ferrari batte l'inferno di Landrover.
   
  È il fuoristrada quando si ha bisogno di una jeep non di un'auto sportiva - intendo se i tuoi requisiti sono irregolari e / o se l'esperienza di lavoro di squadra e di gestione non è così buona, dovrai scegliere Scrum - semplicemente perché provare a diventare convenzionale otterrà sei bloccato - come se la Ferrari fosse bloccata in fuoristrada.}

Per quanto riguarda il "lavoro di più" , penso che uno in attesa di cose del genere probabilmente sottovaluti il ​​QI del programmatore e la sua capacità di adattarsi a varie forme di demenza gestionale .

Finora ho partecipato a due team Scrum realizzando progetti abbastanza diversi in diverse aziende. In entrambe le squadre non ho notato alcun cambiamento nelle mie abitudini rispetto ad esempio a cascata / iterativo.

Sarei orgoglioso di affermare che questo è perché sono così speciale e invincibile ma, francamente, ho visto anche le abitudini di tutti gli altri ragazzi in squadra essere invincibili.

Agile costringe i programmatori a svolgere un lavoro più utile, perché le varie tecniche di sviluppo agile eliminano il lavoro impegnato e il lavoro che non è necessario.

è scomodo fare tutto questo procrastinare quando ci sono due di voi seduti insieme.

Non sono d'accordo. Ho lavorato con un gruppo di fumatori e sono riusciti tutti a fare una pausa insieme per lunghi periodi perché "tutti lo facevano".

comune a rilassarsi nelle prime tre settimane

Questo è un segno di cattiva gestione indipendentemente dalla metodologia. Anche se tra un mese dovessi arrivare un grosso pezzo, mi aspetto di vedere qualcosa alla fine della prima settimana.

non hai niente da dire che potresti vergognarti.

Se sei disposto a masturbarti per tre settimane, penserai a qualche stronzata da dire.

4) Test e feedback - ancora una volta, ti impedisce di mantenere le attività "99% pronte" (quando in realtà è circa il 20%) fino a quando la scadenza non si verifica improvvisamente.

I progetti Waterfall possono avere test e build giornalieri.

Personalmente, odierei scrivere codice e non farci nulla per un mese. Preferisco il ciclo di feedback più breve sul mio codice, sia che si tratti di una recensione codificata o di una disconnessione dell'utente. Far approvare gli altri dal mio lavoro è gratificante. È come il gatto che ti fa cadere un topo sulla porta solo per farti sapere che sta facendo il suo lavoro.

Agile non obbliga gli sviluppatori a lavorare di più , ma a lavorare in modo più efficiente

Esprimere la domanda "forzare gli sviluppatori a lavorare di più" appare un po 'negativo, ma sicuramente è positivo se effettivamente facciamo di più e procrastiniamo di meno?

Detto questo, è un buon punto. Mi sono sentito un po 'stanco di agile quest'anno, ma questo è un enorme vantaggio non scritto che non avevo riconosciuto.

Concordo sul fatto che l'agile può portare gli sviluppatori a essere più produttivi. I tuoi punti su visibilità, responsabilità e tendenza a procrastinare di meno sono tutti veri.

Ma l'agile può e dovrebbe anche portare gli sviluppatori a lavorare di più per motivi positivi: la carota contro il bastone. Fatto bene, l'agile darà agli sviluppatori più interazione con gli utenti, meno beuracracy, più controllo sul loro lavoro, tutto ciò può portare a ottenere di più dal tuo team.

più lavoro non è ancora semanticamente corretto o rilevante per Agile, l'obiettivo è quello di essere più produttivi . In particolare, si concentra sul lavorare di meno sulla cosa sbagliata e di più sul lavorare normalmente sul corretto cosa ; il che non significa lavorare di più , solo in modo più produttivo .

Un effetto collaterale, è che espone i fannulloni e quelli che sono inefficienti o non competenti molto rapidamente. Il che suona più come quello a cui stai arrivando.

La metodologia è irrilevante sul fatto che uno sviluppatore non funzioni o meno . Il processo è, anche in cascata, recensioni di gestione e revisioni del codice possono esporre anche queste cose, ma non in modo così trasparente come la maggior parte delle metodologie Agile.

"Le pistole non uccidono le persone. Le persone uccidono le persone!" È lo stesso con Agile. Agile non fa lavorare di più le persone, i manager fanno lavorare di più le persone.