A sustainable development nem azt jelenti, hogy nincs ostor, hanem azt, hogy nem akadunk meg soha technikai gondok miatt. Ostor folyamatosan van, mert a business mondja meg, mi legyen, changes welcome.
"Nem a változástól lesz motiválatlan, hanem attól, hogy egy barom össze-vissza rángatja a kormányt"
Changes welcome even in the late, ugyebár.
A working software nem egyenlő automatizált teljes körű teszteléssel, egyáltalán nem. A working software azt jelenti, hogy a szoftver működik. Az, hogy hogyan éred ezt el, tök mindegy. Az agilitás nem azt mondja, hogy úgy érd ezt el, hogy teljes körű tesztelésed legyen. Az csak egy eszköz. Elérheted úgy is, hogy teljes körű tervezésed van előre, és minden rész le van vezetve formálisan. Csak éppen ahhoz nem fér meg a "changes welcome" kultúra, cserébe sokkal biztosabb a "working software".
Az egész unit testing, meg CI/CD automatizálás arról szól, hogy a "changes welcome" üzleti kultúráját miként lehet megtámogatni szoftveres eszközökkel. Az agilitás fő kulcsa a changes welcome, minden más pedig az, hogy milyen eszközökkel lehet átlagos fejlesztőkkel ezt elérni.
Kétségtelen, hogy nagyon sokat adott a changes welcome kultúra a szoftvereszközök terén, de sok mindent el is vett. Elvette például az alapos átgondolást - hiszen úgyis changes welcome, szóval változás lesz, felesleges átgondolni a dolgokat. Legyen meg a két hetes sprint, hurrá. Ez is milyen hülye név, aki folyamatosan sprintel, jobban elfárad, mint aki szépen a saját tempójában, megfontoltan halad előre, és tovább is jut.
Az agilitással pont ez a megfontoltság veszett el, hiszen két hétre előre felesleges megfontoltnak lenni, utána meg úgyis minden megváltozhat, és a tesztek úgyis lefednek mindent, nem érdekes.
Pedig a technical excellence, és a problémák folyamatos megértése az nem megy úgy, hogy kéthetente, havonta kibökünk valamit, ami működik, le van fedve teszttel, de magát a problémát még igazán nem értjük és nem ismerjük.
Fred Brooks MMM könyvében lévő szabály jut eszembe: plan to throw one away. Meg kell építened először a komplett rendszert ahhoz, hogy utána rájöjj, hol van benne a valódi probléma, megértsd a rendszer lényegét, és utána le tudd tisztázni. Ez pont ellentétes a changes welcome-mal. Prototipizálásra kiváló, baromi gyorsan lehet iteratív módon ötleteket kipróbálni, megnézni, eldobni, újrahasználni.
De egy rendes fejlesztéshez az kell, hogy azt mondjuk, hogy oké gyerekek, most kérünk két hónapot, amíg rendesen ledokumentálunk mindent, specifikáljuk, hogy mi hogyan működik (hogy ne csak a tesztkódban legyen lefektetve a specifikáció), hogy esetleg más csapattal is lehessen a kód megosztása nélkül a szoftverről beszélni, integrálni azt. Ez nem megy agilisen.