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ć?
19 komentarzy:
Hej,
Jest dużo prawdy w tym wpisie - zwłaszcza kwestia Agile i tego jak to wygląda w praktyce.
Może i mylnie, ale wychodzę z założenia że nie ma narzędzia, metodyki oraz języka który rozwiązywałby wszystkie problemy i zawsze spisywał się tak samo dobrze.
Nie zawsze potrzebny jest Maven, można obejść się bez Scrum, można napisać coś nie używając Javy. Nic nie determinuje sukcesu tak jak ludzie, bo to nie narzędzia przesądzają o wyniku projektu.
W Agile ważna jest ciągłość komunikacji, która daje możliwość wcześniejszego zareagowania na zmiany, ale wcale nie trzeba korzystać ze Scruma żeby móc rozmawiać z klientem o tym, czego potrzebuje, prawda?
Jak zwykle bardzo dobry i ciekawy wpis. W dodatku idealnie utrzymany w lekkim (;)), piątkowym klimacie - rewelacja! :)
w kwestii konsekwencji mam 1000 słów komentarza: http://tinyurl.com/39czj2d
;)
--
Tomek
Twój wzór
Mądrość = Wiedza + Kontekst
zamienił bym na
Mądrość = Wiedza * Kontekst
bo gdy Kontekst jest zerowy to Wiedza na nic ;-)
@Lukasz D. - prawda, prawda
@Łukasz R. - dzięki:)
@Tomek - po prostu trafiłeś w sedno;)
@Łukasz L. - słuszna uwaga, chciałbym się zgodzić ale niestety patrząc na instytucje pedagogiczne widać, że coś na samej wiedzy można jednak zarobić:|
W inżynieri softu jest jak w życiu - balans, potrzebny jest balans. Umiejętności przychodzą z czasem a przynajmniej powinny. Niestety tak jak w życiu mamy niepełnosprytne (nie mylić z niepoełnosprawnymi) osobniki - tak i w IT. Uncle Bob powiedział że trzeba testy - piszemy testy. DDD ma fajne prezentacje na infoq - bierzemy. Tylko po co ? I co ważniejsze - dlaczego ? Tak jak wspomniałeś, takie pytania są już "magicznie", z gatunku filzofowowania. Większośc techonolgii używanych na codzień jest tak prosta (wręcz prostacka nieraz), że można bez większego pomyślenia wyklikac sobie to i owo w kilka minut. Problemy przychodzą niestety.. później. Niewiedza jest błogosławieństwem. Czy nie prościej użyć technologi / metodyki / whatever A B czy C dzisiaj, i cicho przemyśleć co bedzie jutro, za miesiąc, gdy inni przejmą po nas projekt... To kwestia etyki zawodowej i profesjonalizmu. Niestety "etykę i profesjonalizm" też można sobie już kupić dla własnego spokoju. Chyba Uncle Bob oferuje szkolenia z craftsmanship. Ludzię już przetestowali, teraz dorzucą profesjonalizm.
Fajny post ;)
Ale tak to już jest, że onanizm wszelkiego rodzaju (m.in. techniczny) jest przedmiotem reklam i innych zachęt, co jest dość naturalne bo i na rękę wielu osobom. Swoją drogą obserwacja jak przy połączeniu Wiedzy z Bólem powstaje Kontekst jest naprawdę fascynujący.
Swoją drogą już w liceum dane mi było poznać zdanie określające taki stan rzeczy: "Tylko zdechłe ryby płyną z prądem"
A ja myślę, że mimo, że masz rację, to takie podejście rodzi relatywizm. A ten prowadzi do takiego podejścia, że jakkolwiek bym nie robił, to robię dobrze, bo przecież nie ma jednej dobrej drogi (to tak w skrócie).
Ja uważam za cenne takie trochę autorytarne wypowiedzi Uncle Boba i podobnych, bo pokazują właściwy kierunek. Oczywiście do wszystkiego trzeba przyłożyć miarę wszystkich sił działających w projekcie (budżet, skomplikowanie, jakość zespołu, itp.)
Bycie agile to bycie przygotowanym na zmiany. Wybranie maven'a do prosciutkiego projektu to może za dużo, ale zrobienie tego projektu tak, że zmigrowanie go na maven'a będzie trudne też nie jest agile. Agile to nie konkretne praktyki, technologie, czy ogólnie jakieś konkretne wybory, ale cały czas zostawianie sobie pola do zmiany decyzji (Real Options).
http://googletesting.blogspot.com/2010/07/code-coverage-goal-80-and-no-less.html
Idealne podsumowanie Twojego postu. Swoją drogą fajny wpis - lekki humor, bardzo krótko i na temat i pouczająco :)
Zgadzam sie z autorem postu w calej rozciaglosci!
Mozna prosic o wersje po angielsku dla moich zagranicznych pseudo-agilowych wspolpracownikow? Zrobila by ona wiele dobrego, moze ludzie w koncu sie ockną ze samo slowo Agile nie zdziala jeszcze cudu, ze potrzebna jest komunikacja, a nie mowienie o potrzebie komunikacji..
@Anonim - generalnie z rozmów z wieloma team liderami krystalizuje się jeden wniosek: nie każdy osobnik nadaje się do teamu agilowego. Jest to kwestia cech osobowości - ale to temat na osobną historię. Powiedzmy, że czasem tak zwanym mniejszym złem będzie stary waterfall;)
Doświadczenie, nie tylko techniczne, ale ogólno-projektowe jest kolejnym warunkiem niezbędny aby całość funkcjonowała.
Bezrefleksyjne adaptowanie metodyk bez patrzenia na konkretnych ludzi jest oszukiwaniem samego siebie lub kogoś (w przypadku różnego rodzaju konsultantów).
@Sławek - napisałeś "Jest to kwestia cech osobowości - ale to temat na osobną historię. ". Czy to znaczy, że w niedługiej przyszłości możemy spodziewać się nowego wpisu właśnie w tej tematyce? Uważam, że mogłaby to być bardzo ciekawa i pouczająca lektura :)
W książkach, które do tej pory czytałem nt. Agile / Scrum bardzo często powtarza się notka o braniu odpowiedzialności przez członka zespołu, o "spowiedzi" na StandUp meetingach, etc. - Scrum wyciąga wszelkie niedoskonałości społeczno-psychologiczne osobnika na światło dzienne.
Nie każdy ma tak silny kręgosłup by co dziennie spowiadać się ze swoich czynów.
@Łukasz - masz rację, ale z własnego punktu widzenia (praktykanta w zwinnym zespole) mogę powiedzieć, że nie tylko chodzi o siłe tego osobnika, ale także o jego otoczenie. Mi pokazano dlaczego taka "spowiedź" jest dobra, dano mi dobre przykłady i teraz z chęcią dziele się swoimi osiągnięciami codziennie z resztą zespołu.
To nie zmienia faktu, że niektórzy i tak pozostaną "zamknięci" :-(
Jakiś czas temu bawiliśmy się w Scruma (już przestaliśmy :-( ), bez żadnego większego wprowadzenia, etc. Po kilka spotkaniach, czy też iteracji ludzie sami doszli do wniosku, że widzą w tym sens.
Więc każde podejście jest dobre, jednak czy ludzie je zaakceptują zależy od konkretnego osobnika.
(to jeszcze raz ja, Anonim ;) ) Stand-upy są dobre, ale i to samo nadal jeszcze nie wystarczy. Generalnie - jest tak jak piszesz - obok nienagannej komunikacji oraz poczucia odpowiedzialności konieczne są jeszcze wiedza techniczna i doświadczenie ogólnoprojektowe. Niestety w moim projekcie komunikacja i odpowiedzialność są u niektorych czlonkow zespolu na poziomie zerowym, podobnie z doświadczeniem technicznym i 'zarządczym' u decydentów (np. od miesięcy nalegam na przydzielenie dodatkowych programistów do zespołu. zamiast tego przydzielono dodatkowych testerów (owszem tez potrzebni), ale bugi same sie nie naprawia, a teraz odkrytych bedzie jeszcze wiecej.. ale nie mogę sie doprosic o te 'zasoby'). Agile oznacza u nas niestety tylko przesuwanie rolloutu - z marca na kwiecien, z kwietnia na lipiec, z lipca na pazdziernik... :(
Fajny wpis, Sławek, dzięki. Przypomina mi to koncepcję Shu - Ha - Ri, omówioną np. tutaj: http://alistair.cockburn.us/Vid+of+Alistair+describing+Shu+Ha+Ri. Stan, który tak krytykujesz, to właśnie Shu - powtarzanie po nauczycielu/liderze wyuczonych technik, najniższy stopień profesjonalizmu. Ale od czegoś trzeba zacząć. A ten stan idealny, Ri, to właśnie jest wtedy, gdy umiemy użyć technik w odpowiedniej sytuacji. Co więcej, potrafimy je odpowiednio wybierać, wymieniać i dostosowywać do sytuacji.
Warto zauważyć przy tym, że często spotykamy dobrze znane problemy (typy aplikacji), na które istnieją sprawdzone rozwiązania (patterns), warto je więc znać i stosować, a nie za każdym razem na nowo wymyślać koło. To trochę to, o czym pisze Paweł Lipiński. Wierzę, że są pewne podstawy, generalne praktyki, które w większości przypadków się sprawdzają. Trzeba mieć naprawdę mocne powody, by od nich odchodzić (np. od testowania).
Bardzo mądrze napisane. Zwłaszcza te "niemal faszystowskie" punkty, to sedno sprawy. Bardzo często widzę takie podejście i przyznam że mnie to strasznie denerwuje, że ktoś uważa iż kod może być samo-komentujący się. Żenada i jeszcze raz żenada.
W wielu miejscach po prostu ludzie kładą nacisk na szybkość a nie dokładność. Dlatego mamy mnóstwo oprogramowania typu działa, ale nie bardzo kto wie jak. Lepiej nie ruszamy póki działa itp. To chyba nie jest to o co chodzi...
Widziałem już praktyki typu zapisywanie wyrażenia boolowskiego w formie metody składającej się z 7 wyrazów i więcej, po to, żeby kod był samo-komentujący się. Generalnie patrzę w kod gdzie jest 600 linijek czegoś bez kszty komentarza i mnie trafia. Jak można tutaj zrozumiec choćby logike biznesową kodu, gdy nikt nie pokusił się wyjaśnić co to właściwie robi. Metoda w stylu GetSomeParams nic nikomu nie powie.
Naprawdę przestrzegam przed tego typu praktykami. Osobiście komentuje sporo i uzywa doxygene.
Prześlij komentarz