Disclaimer: ciò che segue sono solo le mie opinioni, con la mia esperienza limitata di 4 luoghi di lavoro.

First, I think the most important is the people you work with. I kind of like the term "peopleware". Because in the end we do the software, not some methodology. And the results highly depends of the people involved and they work together.

Regarding the methodology, I think applying either in their "pure" form sucks badly. The ideal IMHO is something in between that fits the team/project.

Cascata

"Plan first, then do!"

Come si può fare bene

Ha senso chiarire cosa dovrebbe essere fatto e come prima di scrivere tutto il codice, specialmente se si tratta di un progetto abbastanza grande. Per prima cosa analizzi ciò che dovrebbe essere fatto, quindi dividi il lavoro, poi fallo. In realtà è abbastanza efficace. Cascata non significa che sia scritta nella pietra. Ovviamente lo si reiterra e lo si aggiusta man mano che si procede. È solo che pianifichi cosa fare prima di farlo invece del contrario.

Come può andare male

Ovviamente è possibile fare disastri. La distanza tra "l'architetto" e gli sviluppatori, le cose su ingegneria, con molta interferenza, e quando viene richiesto un cambiamento, la gente alza le braccia dicendo "che non era nelle specifiche". Anche se non deve essere, ha una tendenza ad esso.

Agile

"Let's start and adapt as we go on!"

Come può andare bene

Penso sia ideale per i progetti più piccoli o quando il risultato finale è piuttosto sfocato, che in realtà è abbastanza comune nella mia esperienza. Inoltre, se i clienti hanno un prototipo con cui possono giocare, può essere molto utile per il feedback o per chiarire i dettagli. È un processo molto adattivo e il progresso è più visibile.

Come può andare male

In primo luogo, può essere un dolore riscrivere tutto ogni mese a causa di costanti cambiamenti o capricci. Inoltre, spesso, il codice temporaneo diventa permanente e "dovrebbe essere fatto dopo" rimane per sempre, portando a un reparto tecnico che si accumula man mano che il software cresce. IMHO c'è un po 'troppo di micro-gestione nella roba SCRUM. Invece di potenziare gli sviluppatori, li tratta come robot.

Storia laterale, proprio come un aneddoto. In un progetto in cui mi trovavo, abbiamo avuto un incontro giornaliero con una squadra di 15 ragazzi. Era semplicemente una sciocca perdita di tempo, tutti parlavano di dettagli specifici che nessun altro aveva compreso o curato.

Luogo di lavoro attuale

Nel mio posto di lavoro attuale, siamo abbastanza "senza processo" e penso che funzioni abbastanza bene. In realtà è davvero semplice . Ci incontriamo una volta alla settimana in una piccola squadra, facciamo una piccola chiacchierata su progressi, eventi e su cosa dovrebbe essere fatto in seguito. Questo è tutto. Tutto il resto spetta al dev. Nessun tempo stimato, nessun programma, nessun rapporto, nessuna gestione in sé, solo: "ok, la prossima cosa che dovremmo fare è XYZ ... e se hai ancora tempo, c'è anche l'ABC. Fai come vuoi". Di solito le attività richiedono giorni o settimane. Separatamente, ci sono segnalazioni di bug che dovrebbero essere risolte con priorità, ma queste non sono troppe.

Conclusione

IMHO strictly following either methodology won't write better software. Having friendly contact, competent co-workers, clear objectives and being heard will do.

i miei 2 centesimi

Ho lavorato a progetti di successo e non di successo, alcuni dei quali usati come agili e altri no. Nel complesso, direi che ciò che differenzia i progetti soddisfacenti da quelli che non lo sono è la presenza o la mancanza di una buona gestione del progetto. Quindi, i progetti di successo non agili hanno avuto riunioni di team regolari (non necessariamente tutti i giorni) e anche una buona gestione del progetto in cui le mansioni sono state assegnate in modo intelligente a coloro che hanno avuto la maggiore esperienza.

Classificherei "agile" come parola chiave. Tutti ne parlano in questi giorni. Tuttavia, per progetti di sviluppo software di grandi dimensioni (oltre 10 anni, 7-70 persone), è opportuno considerare le persone non come identiche, ma come individui con competenze diverse e conoscenze diverse di varie parti del codice base. Esattamente il contrario di ciò che significa "agile". In una società in cui lavoravo, stavamo ufficialmente utilizzando Scrum, ma il processo è stato adattato alla natura speciale del grande (10+ anni, 70 persone) del progetto di sviluppo software. Quindi non molto "agile" dopotutto ... E forse è per questo che ha funzionato.

Per piccoli progetti in cui tutte le persone sono competenti e c'è così poco codice così banale da non sviluppare particolari e diverse competenze in alcune parti della base di codici, direi che l'agile potrebbe essere il metodo migliore. Ma per progetti a lungo termine, certamente non lo è, a meno che non sia così pesantemente modificato che non puoi più chiamarlo "agile".

How come my Waterfall projects were largely more satisfying than all those new “agile” projects?

Se dovessi indovinare, la nostalgia. È più soddisfacente ottenere questo grande progetto di sei mesi rispetto a questa stupida piccola 2 settimane di lavoro - questo non significa che sia stato fatto meglio (in tempo, sul budget). E, naturalmente, c'è anche il problema che la maggior parte dei posti sono solo di tipo Agile. Dicono che sono agili, hanno le stesse cerimonie, ma non hanno la mentalità.

Ad esempio:

nowadays, everyone around me hates being suffocated by "agile" processes, tiny tasks and massive control machinery around

Quindi cambia. Sei una squadra auto-organizzante, giusto? Una pietra miliare di molti approcci Agile?

Anche se non lo sei, dovresti sicuramente rispettare "Individui e interazioni su processi e strumenti". È letteralmente la riga n. 1 del manifesto agile!

One thing I don't get at all is why more process, and more control, should ever make software development better?

Ci sono situazioni in cui può, ma le probabilità sono che non lo faranno. Da qui il manifesto n. 1.

Detesto ripetere le cose che hai ascoltato e vorrei che le cose andassero meglio per te, ma le tue aziende stanno sbagliando. Hai ragione che è difficile da fare. È difficile per le persone fidarsi l'un l'altro. Abbi fiducia che le persone possano prendere buone decisioni senza processo. Abbi fiducia che se facciamo delle scelte verso l'obiettivo, alla fine ci arriveremo. Confida che l'interazione individuale stia avvenendo ed abbia efficacia piuttosto che avere incontri e supervisione e una gestione dei microgestione onerosa.

Penso che "Agile" funzioni bene, ma quando lo dico intendo:

• 5 a un team
• Sprint della settimana
• Stand-up quotidiano: punti al compito che hai svolto ieri e stai lavorando oggi e l'unica volta in cui hai qualcosa di più di "Ho fatto questo, ora sto facendo questo" per dire è se sta andando male. Fondamentalmente è solo un appello.
• nessun retros, nessuna pianificazione, nessuna stima. Togli dal backlog e assegna nuovi compiti quando ci pensi.
• Distribuisci / Demo alla fine della settimana.

Funziona quando hai persone che sanno cosa stanno facendo "scrivimi un'app / sito web / flusso di lavoro aziendale / qualsiasi cosa" e disponi degli strumenti necessari per farlo (lingua scelta, dev env, produzione env)

Risolve 2 problemi

• Problema della grande azienda : dobbiamo fare mesi di raccolta dei requisiti e di scrittura dei documenti prima ancora che possiamo iniziare la programmazione e tutto viene ignorato comunque.

• Problema Small Company : gli sviluppatori dicono che stanno lavorando ma non ho idea di cosa o quando saranno finiti o se funzionerà alla fine di esso.

Le mie ipotesi sul motivo per cui agli sviluppatori spesso non piace sono:

• Gli sviluppatori non vedono il problema della Big Company. Otteniamo le specifiche ben definite e scriviamo un codice che lo soddisfi. Facile.
• Gli sviluppatori MI PIACE il piccolo problema della compagnia, diventiamo tutti rock star startup rock siliconata! ciao!
• Scrum ha un miliardo di incontri e gli incontri sono merda.
• La stima è un lavoro duro e ingrato.
• Gli sviluppatori HATE addetti alle vendite e 'agile coach' / consulenti / maestri di scrum / Martin 'così chiamato' Fowler se questo è il suo vero nome! ecc stanno fondamentalmente vendendo agile.