Agile di lavoro su Mainframe [chiuso]

Suppongo che ci siano due fattori che portano a questo:

1. I mainframe vengono utilizzati per le applicazioni per le quali Waterfall è solitamente più adatto:

   • Molte applicazioni mainframe sono business-critical o life-critical: questi progetti richiedono molta documentazione e non si adattano bene con Agile.

   • Raramente si vedono i mainframe nelle start-up. I mainframe sono piuttosto usati dalle agenzie governative, dal settore sanitario e dalle istituzioni finanziarie. Queste entità hanno l'abitudine di usare Waterfall, definendo il costo del progetto prima del suo inizio (oltre a redigere la specifica dei requisiti).

2. I mainframe sono usati dagli sviluppatori che sono abituati a Waterfall più di Agile. Hanno lavorato con Waterfall per decenni e potrebbero non accettare necessariamente di cambiare radicalmente i loro metodi.

   Allo stesso modo, indovina dove un giovane sviluppatore interessato da Agile cercherà un lavoro? In una start-up o in un'agenzia governativa?

Ci sono molti motivi:

• Mindset: molti sviluppatori che lavorano su mainframe fanno il loro lavoro per decenni. Sono "cresciuti" con la caduta dell'acqua e non sono esposti tanto alle nuove idee quanto ad altri ambienti in cui lo sviluppatore medio ha forse 5 anni di esperienza e porta molte nuove idee al tavolo.

• L'ambiente: molte cose che codificano sono strettamente legate a un database. Anche i componenti che creano sono spesso strettamente accoppiati. Questo ostacola molto il testing automatico, che è una delle basi importanti degli approcci agili.

• Strumenti: gli strumenti che devono vivere sono spesso orribili. Spesso non hanno alcun framework di test né un controllo di versione che sia accettabile per altri sviluppatori. Le build automatiche come Java / C # / che gli sviluppatori si aspettano siano inaudite.

Naturalmente i diversi motivi si influenzano a vicenda e normalmente li rafforzano ancora di più.