ThoughtWorks - relacja

Na wyklad przyszla ponad setka osob.

Wolf Schlegel: "Dos and don'ts of Continuous Integration and Delivery"
Wolf zadal takie oto pytanie: Ile czasu zajmuje dostarczenie nowej wersji na produkcje po dodaniu jednej linijki kodu?
Mozliwos szybkiego i sprawnego dostarczenia nowej wersji jest kluczowa. Decyzja o tym kiedy nowy releas wejdzie na produkcje jest sprawa marketingowa, umiejetnosc zrobienia tego jest sprawa techniczna. I ta umiejetnosc czesto przesadza o tym kto zagarnie nowych klientow.
Znane sa sytuacje kiedy programista nie zdarzyl sie wyrobic i pewna czesc funkcjonalnosci przesunieta zostala do kolejnego release (np. na 3 miesiace)
bo taki jest plan.
A co gdyby po kazdej wprowadzonej zmianie mozna bylo miec mozliwosc latwego dostarczenia nowej wersj na produkcje?
Oznacza to m.in.:

• latwosc zarzadzania wersja
• sprawne przeprowadzenie testow (np. automatyzacja)
• sprawny proces budowy nowej wersji, sprawny deployment (lacznie z backupami danych)
  

Erik Dörnenburg: "Lean for enterprise architecture"
Erik twierdzi, ze architektura oprogramowania ma wbrew pozorom wiecej wspolnego z ogrodnictwem niz z klasyczna architektura i budownictwem.
Tu przpomina mi sie czesc artykulu Martina Fowlera http://www.thoughtworks.com/the-new-methodology. Jakims sposobem zapamietalem prawi nic z jego sesji ale moze dlatego ze
nie bylo w niej nic nowego poza tym co napisal Fowler we wspomnianym artykule. Musze jednak zaznaczyc, ze sesja Erika podobala mi sie najbardzie.

Martin Fowler: "Software Design in the 21st Century"
Na tego pana czekalem z duzym zainteresowaniem. Do tej pory czytalem tylko jego ksiazki, bloga i artykuly. Tym razem mialem okazje chwile go poobserwowac i zamienic slowo.
Martin opowiadal o wzkorzystaniu podejscia przy projektowaniu. Glowynm argumentem za bylo mozliwosc przywrocenia systemu do danego stanu za pomoca zalogowanych eventow.
Latwa reprodukcje defektow na podstawie sekwencji eventow. Mozliwosc badania systemu w roznych stanach i latwosc uzyskiwania tach stanow. Szczegoly sa tu http://martinfowler.com/eaaDev/EventSourcing.html

W drugiej czesci omawiany byl software design ogolnie. Nie obylo sie bez Uncle Bob i kwesti moralnej kazdego programisty wsickajacego codziennie guzik(i). Poruszony zostal rowniez temat dlugo technicznego (technical debt) http://martinfowler.com/bliki/TechnicalDebt.html. Jak to z kazdym dlugiem, trzeba go kiedys zwrucic, czesto z odsetkami. Chodzi tu o sytuaje kiedy management cisnie na zrobienie czegos na wczoraj zeby dzialalo, nie wazne jak, zaby tylko klient mogl przeklikac. I nie ma nic w tym zlego. Kredyty sa zaciagane na przerozne rzyczy. Jedyne o czym trzeba pamietac to splata - ona kiedys nastapi. Moze nie podczas trwania projektu, a juz w fazie utrzymania. Nie wazne - zaplacic wkoncu trzeba, a zaplaci pewnie klient.

We wszystkich wystapiniech czuc bylo mocno podejscie adaptacyjne i nacisk na bardzo bliska wspolprace z klientem oraz profesjonalizm w wytwarzaniu oprogramowania. Wszystko po to zeby stworzyc nie tyle sam produkt ile srodowisko pozwalajace przygotowac taki produkt, ktory da sie:

• latwo dopasowac do zmian na rynku (dodanie nowzch funkcjonalnosci, zmiana istniejacych) good design
• sprawnie wprowadzac na rynek - WPROWADZAC i WPROWADZAC ciagle - continues integration and delivery
• tworzyc przy nierozlacznej wspolpracy biznesu z IT - klient jest aktywna czescie zespolu tworzacego oprogramowanie

W tym srodowisku najwazniejsi sa ludzie. "Put people first" i moja parafraza pewnego sloganu "People matter, results come". Ten caly agile jest po prostu dla ludzi, a nie dla projektow czy tam procesow. To znaczy, sa ludzie, ktorzy beda w takim systemie dobrze pracowali i sa tacy ktorym on bedzie nie na reke. Jednak te male robaczki z samego dolu programistycznego padolu sa waze, a nawet bardzo. Nazywane przez niektorych resource'ami sa jak to pisze Fowler indywidualnosciami przeznaczonymi do tworczej pracy. Jak to wlasciwie jest ?