Projekty Informatyczne - Mity ;-)

Z wykształcenia jestem fizykiem, z zawodu i zamiłowania programistą, ostatnio pełnię jeszcze rolę development leada [mówiąc prosto jestem tym na którego wszyscy mogą krzyczeć ;-), dokładniej zaś sprawę ujmując jestem kimś kto łączy developerów z product managerem [używam nazw anielskich bo lepiej oddają znaczenie]]. Moja wiedza więc o programowaniu i prowadzeniu projektów jest mieszanką praktyki nabytej w paru firmach, własnych lektur oraz pewnych szkoleń. Po tym przydługim wstępie przejdźmy do mitów :-)Harmonogramy.
Idea jest piękna i słuszna - każdy wie co, kiedy i w jakim czasie ma zrobić, dzięki temu można podać daty tego kiedy produkt będzie dostępny, można planować kolejne releasy i tego typu sprawy.
Rzeczywistość jest taka, że gdy harmonogramy są ułożone przez kogoś kto je rozumie cały zespół zaczyna grać na harmonogram ;-) Nic nie robisz od dwóch tygodni i przez następne dwa nic nie będziesz robić? Chcesz iść w takiej sytuacji na urlop? Nie możesz, bo jak wprowadzi się Twój urlop do super programu okazuje się, że data zakończenia przesunie się o tydzień....
Częściej jest jednak tak, że harmonogram układa się dla ułożenia. Wiemy, że klient życzy sobie produktu za 3 miesiące więc tak budujemy harmonogram by na papierze trwało wszystko 3 miesiące ;-)Z moich doświadczeń widzę, że najlepszy model w tym przypadku to coś podobnego do Scrum'a [choć bez dodatków które tylko denerwują ludzi]. Developerzy to zwykle dość inteligentni ludzie i potrafią zarządzać swoją pracą tak by zmieścić się w terminach. Wtedy product manager musi wyznaczyć tylko ogólne ramy czasowe, a wszystko się samo ułoży. Dodatkowo developerzy widzą zwykle zależności czasowe i starają się samo-organizować tak by jedyną osobą na którą trzeba czekać z wykonaniem kolejnej czynności była osoba która ją wykona ;-). Jak zauważyłem takie podejście świetnie działa w małych zespołach do 5-6 osób, w większych nie miałem okazji oglądać takiego podejścia.
Zarządzanie.
Jest ważne, sęk w tym że z uporem maniaka wszędzie uczy się takiego prowadzenia projektów w którym developer sprowadzany jest do niezbyt rozgarniętego trybika. Mówiąc inaczej - do zarządzania inteligentnymi i odpowiedzialnymi ludźmi stosuje się metody stworzone do zarządzania normalnymi ludźmi. Taka mała dygresja, przeciętny developer choć w swojej grupie jest przeciętny, to w ogóle populacji utrzymuje się w górnych stanach populacji [im firma lepiej płaci tym wyższe stany to są :-)], mówiąc jeszcze inaczej częsta może być sytuacja w której szeregowi podwładni są inteligentniejsi od menadżera prowadzącego projekt. Dobrzy menadżerowie to wiedzą [i tu też zasada im firma lepiej płaci tym więcej menadżerów którzy to wiedzą :-)] i cieszą się z tego.
Konsekwencją tego stanu jest to, że w większości przypadków developerzy tym lepiej pracują im więcej wiedzą o projekcie, ale w standardowym zarządzaniu gdzie traktowani są jak tribiki nikt im nic nie mówi ponad to co muszą wiedzieć.
Rozwiązanie jest proste - Agile - czyli w najbardziej skrajnym przypadku ;-) totalna samoorganizacja, ludzie sami wprowadzają procedury i standardy. Wystarczy dać im tylko ramy, które stanowi system do bug-trackingu i repozytorium kodu. Wtedy działa to tak, że z jednej strony, poprzez system bug-trackingowy, wrzuca się oczekiwania, a z drugiej strony odbiera się produkt :-)Z doświadczenia powiem, że dla małych projektów z 5-6 developerami to działa na pewno :-)Configuration Management.
Tak naprawdę nikt do końca nie wie co to jest.... oczywiście są ludzie którzy się tym zajmują i wiedzą więcej, ale i tak dla przeciętnego zjadacza obwarzanków sprowadza się to do tego, że jakoś trzeba pracować na aktualnym kodzie jednoczenie mogąc pracować w kontekście "historycznym" ;-)Rozbuchane zasady z mnóstwem gałęzi, splitów, integracji i tym podobnych świetnie wygląda na papierze, ale zwykle jest całkowicie niepotrzebne.
Continous Integration i to w wersji najprostszej, czyli pracy na wspólnym kodzie nawet bez build centerów, automatycznych testów i podobnych pozwala na obejście większości problemów. W końcu jak duża jest szansa, że 2 lub więcej ludzi z 6 osobowego zespołu dotknie tego samego kodu i sobie będzie wzajemnie przeszkadzać? Niewielka, choć szacunkowo zdarza się to w 10-15% przypadków ;-) i narzut wynikły z opóźnień tym spowodowanych jest o wiele mniejszy niż ten wynikły z walki z gałęziami.
Dokumentacja.
To jeden z największych mitów ;-) Wszyscy chcą dokumentację do projektów [sam nieraz chciałem], ale nikt jej nie tworzy ;-) A gdy wymogi każą ją tworzyć to jest traktowana po macoszemu i nikomu nie chce się jej później aktualizować [co zwykle oznacza przepisywanie].
Sens ma dokumentowanie punktów styku między podsystemami, interfejsów, protokołów komunikacji i zamotanych algorytmów, do tego dochdzą jeszcze sytuacje gdy coś jest regulowane przez prawo i trzeba to zaimplementować, wtedy też dobrze napisać dokumentację jak to ma działać. Dobrze jest jeszcze udokumentować pewne szkielety rozwiązań i zrobić listę przykładów do naśladowania i do unikania. Choć może się okazać, że i to by było zbyt dużą liczbą dokumentów. Zwykły JavaDoc wystarcza ;-)Podsumowując mogę stwierdzić, że do developmentu próbuje się wprowadzać formalizm, ale on często zamiast pomagać zabija twórcze podejście. Brak formalizmu jest zły, ale życie dla formalizmów jest jeszcze gorsze. Najzdrowszym podejściem jest podejście rozsądne ;-) Które można wyrazić jako niedogmatyczne trzymanie się zasad ;-)

Podobne posty^beta
Starzeję się ;-)
Kiedy zmieniać pracę i po co? (w IT)
"Ja? Niech ktoś inny płaci" ;-)
Mam milion rzeczy na głowie... co robić?
Język a postrzeganie rzeczywistości