Agile costringe gli sviluppatori a passare più tempo a lavorare?

L'idea principale dietro i metodi agili è quella di aiutarti a essere produttivi, in senso positivo. A nessuno importa se passi un'ora a navigare ogni giorno se rispetti la scadenza. Ognuno si arrabbia se si naviga mezz'ora ogni giorno, ma manca la scadenza. La soluzione: semplifica il rispetto della scadenza.

Come hai notato, la programmazione della coppia ti assicura di rimanere concentrato (tra tutti gli altri vantaggi come migliorare la diffusione di competenze / conoscenze, codice migliore, meno bug, design uniforme, ecc.)

Ho trovato che la disciplina è sempre una lotta per me. Se accoppiato con qualcuno, è probabile che uno di noi voglia fare un po 'di lavoro oggi e tiri fuori l'altro. Quindi il "lavoro per un mese" diventa spesso "lavoro insieme per una settimana", essendo sorpresi di come quell'enorme quantità di lavoro sia stata risolta alla fine, impiegando circa un giorno a recuperare (rifattorizzare, correggere TODO nel codice, aggiungere un un paio di test, navigando con la coscienza pulita) e poi afferrando il prossimo mese di lavoro.

Risultato netto: sono molto più rilassato (più perché nonostante la supervisione costante), la coesione delle squadre è molto migliore, il lavoro viene svolto più velocemente, le persone non si attardano su un problema minore per ore o addirittura giorni (perché qualcun altro può individuare il problema molto più velocemente).

Quando dici "potresti vergognarti", non è una buona cosa? Significa che senti di aver sbagliato e che dovresti. Non sei pagato per non fare nulla. Non ottenere nulla ti fa sentire indifeso, infelice, indegno, infelice. Invece di vergognarsi, tirati indietro e pensa "Perché oggi non ho realizzato niente?" 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: Assumi responsabilità invece di essere microgestito come un fantoccio su archi. Hai bisogno di uno strumento? Vai dal tuo capo e chiedilo. Impara a discutere. Impara a alzarti e urla quando devi.

Per quanto riguarda i test, c'è un punto debole quando il tuo codice collassa improvvisamente da "bello" a "perfetto". Questo è il momento in cui ti accorgi 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 divennero improvvisamente un giorno. Vittoria! Triumph!

Sono d'accordo.

Pair programming

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

Short stories

Team communication and cohesion

Testing and 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 (incluso ovviamente nella gestione).

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

• Rende impossibile che la gestione non collabori correttamente.

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

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

Agile usato come strumento di pressione? Certo, l'ho visto molte volte. Semplicemente peggiora le cose.

Do you feel that under Agile you work more than under "conventional" methodologies? Is this pressure compensated by the more comfortable environment and by the feeling of actually getting right things done quickly?

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

È una specie di pressione positiva. Questo è molto diverso da alcuni esterni "sei già in ritardo sul programma, lavora di più, codice straordinario!" -nessione di pressione.

In realtà, sono molto più produttivo quando uso i metodi convenzionali. Con il metodo convenzionale, creo ad es. un'analisi dettagliata dei requisiti, uno studio di fattibilità, una specifica funzionale, una specifica tecnica e molti protocolli di riunione, il tutto nel giro di pochi mesi! Potrei persino creare alcune linee di codice una volta che l'analisi di impatto è stata fatta!

Agile, tutto ciò che creo sono alcuni risultati finali.

Nella nostra azienda,

Programmazione di coppie - Quando qualcosa di veramente complesso e richiede un'analisi approfondita, anche noi metteremo due persone eccellenti insieme e svolgeremo l'attività in tempi rapidi. Qui la complessità del compito decide la necessità della programmazione della coppia.

Racconti brevi - Quindi rallentare 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 circa 8 ore al giorno e mantieni il tuo programma stabile e questo sembra sempre COOL.

Comunicazione e coesione del team - Nella riunione di mischia condividiamo non solo lo stato del compito, ma anche gli ostacoli. Qui, quando qualcuno ha davvero bisogno di aiuto, gli altri membri potrebbero venire con le loro idee per aiutarlo. Ma sicuramente hai bisogno di un Team eccellente per questo e noi siamo:)

Test e feedback - Sicuramente come sviluppatore non voglio essere carico di Bugs alla fine, un attimo dopo aver trovato un bug è stato quello di risolverlo e di nuovo, questo mi avrebbe permesso di avere una buona previsione di cosa dovrebbe / può essere fatto dopo e riprogrammare la scadenza (se necessario) di conseguenza.

Quindi, come sviluppatore, sono molto contento del tipo di compito che prendo e sicuramente posso dire di non aver mai provato la vera pressione della scadenza.

Do you feel that under Agile you work more than under "conventional" methodologies?

• Se vuoi dire che mi sento più produttivo con Agile, direi dipende .
  
  <sub>Di solito la penso in termini di Ferrari (come convenzionale) contro Landrover (come Scrum). Quando si guida su un'autostrada, la Ferrari batte fuori da Landrover.
  
  È fuoristrada quando si ha bisogno di una jeep non sportiva - voglio dire se le vostre esigenze sono irregolari e / o se la squadra lavora e l'esperienza di gestione non è così buona, dovrete scegliere Scrum - semplicemente perché provare ad andare convenzionale otterrà sei bloccato - come la Ferrari sarà bloccata fuori strada.</sub>

Come per "lavorare di più" , beh, penso che una cosa del genere sottovaluta probabilmente il QI del programmatore e la sua capacità di adattarsi a varie forme di demenza di gestione .

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

I would be proud to claim that this is because I am so special and invincible but frankly, I've seen habits of all other guys in team being invincible, too.

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

it is inconvenient to do all that procrastination when there are two of you sitting together.

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

common to slack off in the first three weeks

Questo è un segno di cattiva gestione, indipendentemente dalla metodologia. Anche se un pezzo enorme è dovuto in un mese, mi aspetterei di vedere qualcosa alla fine della prima settimana.

you have nothing to say you may actually feel ashamed.

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

4) Testing and feedback - again, it prevents you from keeping tasks "99% ready" (when it's actually around 20%) until the deadline suddenly happens.

I progetti a cascata possono avere test e build giornalieri.

Personalmente, odio scrivere codice e non avere nulla da fare per un mese. Preferisco il ciclo di feedback più breve sul mio codice, indipendentemente dal fatto che si tratti di una recensione codificata o di un accesso utente. Avere altri che approvano il mio lavoro è gratificante. È come se il gatto ti lasciasse un topo sulla porta di casa solo per farti sapere che sta facendo il suo lavoro.

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

Affrontare la domanda "costringendo gli sviluppatori a lavorare di più" si presenta un po 'negativo, ma sicuramente è positivo se effettivamente otteniamo più risultati e procrastiniamo di meno?

Detto questo, è un buon punto. Quest'anno mi sono sentito un po 'stanco di agilità, ma questo è un enorme beneficio non scritto che non stavo riconoscendo.

Sarei d'accordo sul fatto che l'agilità possa portare gli sviluppatori a essere più produttivi. I tuoi punti sulla visibilità, la responsabilità e la tendenza a procrastinare di meno sono tutti molto veri.

Ma agile può e dovrebbe anche portare gli sviluppatori a lavorare di più per ragioni positive - la carota contro il bastone. Fatto bene, 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ù funzionante non è ancora semanticamente corretto o rilevante per Agile, gli obiettivi devono essere più produttivi . Si concentra in particolare sul lavoro less sulla cosa sbagliata, e più sul normale funzionamento della cosa correct ; che non significa lavorare più , solo più produttivamente .

Un effetto collaterale, espone i rallentatori e quelli che sono inefficienti o poco competenti molto rapidamente. Che suona più come quello che stai ricevendo.

La metodologia è irrilevante sul fatto che uno sviluppatore non sia non funzionante . Il processo è, anche a cascata, le revisioni di gestione e le revisioni di codice possono esporre anche queste nozioni, 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.