Inżynieria oprogramowania w ujęciu systemowym.
Zintegrowane podejście do metodyk,
technologii (głównie Java EE), architektury i rozwoju ścieżki kariery programisty.
czwartek, 1 lipca 2010
Bo w życiu trzeba... być Agile:)
Od dzieciństwa słyszmy ze strony różnych "dobrych wujków" co jest "w życiu ważne". Niestety rzadko zdarza się usłyszeć o adaptacyjności czyli życiowej zwinności (w sensie agilności).
Jadnak jakimś cudem w IT wszyscy są Agile - jakiś czas temu robiłem mały research, podczas którego z trudem znalazłem jedną firmę, w Indiach, która otwarcie mówi, że nie jest Agile;)
Gdy jednak przyjrzeć się bliżej, to z tym Agile jest jak z seksem u nastolatków - każdy o tym mówi ale niewielu tak na prawdę to robi (a przynajmniej tak było kilkanaście lat temu w klasach mat-inf;)
Mówi się, że Agile jest trudny ponieważ z pozoru wydaje się łatwy - tak łatwy, że wszystkim wydaje się, że zrozumieli.
W niniejszym poście nie będę pisał o problemach z metodykami (przy okazji: metodologia to nauka o metodykach). Skupimy się na materii miękkiej, czyli problemach z ludźmi.
Jak często napotykacie niemal faszystowskie, anty-adaptacyjne postawy typu:
- nie pisz komentarzy, pisz samo-komentujący się kod (ale samo-komentujący z czyjego punktu widzenia?)
- dobry kod powinien mieć 70% komentarzy tak aby dało się go odtworzyć czytając je (ale po co?)
- Stories są lepsze/gorsze niż Use Case (na jakim poziomie?)
- YAGNI i KISS (nawet jeżeli mam intuicję, że się przyda?)
- Java rules/.NET rules (ale czym to się różni?)
- zawsze używajmy IoC i ORM (ale dlaczego i po co?)
- ORM to badziewie, tylko SQL w procedurach (ale jakim kosztem?)
- jak baza to tylko Oracle/Postgres/... (ale do każdego projektu?)
- jak baza to tylko noSQL (bo jest sexi?)
- zawsze pisz testy - "you are not allowed to write a single line of production code without test first" - grzmiał jakiś czas temu Uncle (nomen omen;) Bob
- powinieneś mieć co najmniej 80% pokrycia testami (a dlaczego nie 85%? settery też?)
- nie pisz testów nigdy (nigdy?!?)
- metody powinny mieć 5 linijek (za 6 pójdę do więzienia?)
- metody powinny być tak długie, że powinno dać się je zrozumieć w 5 minut (ale zrozumieć przez kogo)
- zawsze używaj Mavena (nawet w jednomodułowym projekcie z 10 libami?)
- statyczne języki są lepsze (lepsze do czego?)
- dynamiczne języki są lepsze (szczególnie jak do klasy String dokleję sobie 150 metod
- przeglądarka/system/IDE X jest lepsze (lepsze do czego? mówisz to aby pomóc czy aby się podroczyć?)
Można by tak mnożyć w nieskończoność...
Nie wiem czy jest to przypadłość jedynie naszej branży, ale tym co hamuje Agile w procesie jest Autorytaryzm w ludziach. Być może autorytaryzm jest ogólnym memem "odziedziczonym" po wspomnianych w pierwszych zdaniu wujaszkach. Być może jest on wbudowany w nasze ścisłe umysły jako ich integralny ficzer - taki koprocesor poszukiwania jednego, naiwnie prostego równania na wszystko.
O ile mamy coraz więcej KNOW HOW to często brakuje KNOW WHEN.
Można ująć to inaczej: w równaniu
Mądrość = Wiedza + Kontekst
najważniejszy jest kontekst. Kontekst jest tym co odróżnia teorię od praktyki. Kontekst pozwalający zaadaptować wiedzę. Kontekst, który w Modelu Kompetencji Braci Dreyfus pojawia się z czasem, z doświadczeniem. A doświadczenie to refleksja. Refleksja jest konieczna do adaptacji podejścia.
//=================================
W większości cywilizacji konsekwencja jest cnotą. Zwrot "nie jesteś konsekwentny w swym postępowaniu" ma mocno pejoratywny wydźwięk.
Ale bardziej Agile jest inne podejście - podejście adaptacyjne: "Konsekwencja jest fortecą głupców". Konsekwencja zwalnia z obserwowania, myślenia i dostosowania się (nie należy mylić konsekwencji z wytrwałością).
Nie chodzi o to aby zafiksować się na czymś, spuścić głowę i konsekwentnie ryć niczym świnia za truflami. Co jakiś czas warto ją podnieść sprawdzić czy cel jest jeszcze wciąż na wprost - a może na horyzoncie pojawił się inny, lepszy cel i warto się zaadaptować?
Subskrybuj:
Posty (Atom)