Przeczytałem jakiś czas temu podręcznik nowych pracowników Valve i byłem szczerze zachwycony. Polecam lekturę wszystkim chętnym. Wyciągnąłem z tej broszurki sporo przemyśleń, a jedno z nich dotyczyło tego, jak się rodzą projekty. O tym za chwilę, a teraz...
Modele powstawania oprogramowania
|
| Photo by law_keven |
Podręczniki i kursy programowania karmią nas modelami powstawania oprogramowania. Jest ich kilka, zazwyczaj nacisk kładzie się na Waterfall i na bazie jego wad i zalet omawia się inne. Kończymy studia, okazuje się że z Waterfall'a nie korzysta prawie nikt i po przeczytaniu paru ogłoszeń o pracę, nerwowo zaczynamy wyszukiwać hasła "scrum", "agile", "extreme programming", itd. Od paru lat na topie jest Agile Development, co dla niektórych oznacza "siadamy i napi***my" (autentyczny cytat). Oczywiście nie na tym polega bycie Agile, ale to już pozostawiam dociekliwym do sprawdzenia.
W końcu dostajemy jakąś pracę i jeżeli trafimy naprawdę dobrze, to okazuje się, że rzeczywiście jest Scrum Master, robimy Sprinty i cały ten jazz, ale... coś nie gra. Model nie przystaje do rzeczywistości, bo dzieją się rzeczy, które do niczego nie pasują. Pewnego wtorkowego poranka okazuje się, że córka siostry Stefana się rozchorowała i nie przyszedł do pracy, a trzeba koniecznie dostarczyć to, co akurat robił. Albo klient dorzucił najważniejsze wymaganie w środku sprintu, które oczywiście musi być dostarczone natychmiast. Wtedy okazuje się, że złotą regułą wszystkich modeli jest "jeżeli klient odpowiednio (do)płaci, to róbcie co każe".
Ja, o dziwo, obecnie pracuję w Waterfallu na sterydach: czystym, pięknym i objętym ogromną biurokracją. Rzeczywistość nadal obowiązuje i nadal dzieją się rzeczy, których nie da się łatwo opisać w kategorii jakiegokolwiek modelu. Nie oznacza to, że model od razu wyrzucamy do kosza. Model zostaje, my robimy to, co trzeba zrobić, a potem... zaczyna się naginanie trupa do trumny. Zdarzało się, że zmiana 3-4 linijek kodu generowała mi zajęcie na cały dzień pracy; bywało i więcej. Wydaje się chore, ale nawet za trzy lata, po chwili szukania, będę w stanie powiedzieć bardzo dokładnie dlaczego zmieniłem te linijki kodu i jakie konsekwencje dla całego projektu miała ta zmiana, a projekt mały nie jest. Nie jestem fanem tego wszystkiego, ale widzę zalety na tym etapie projektu.
Powstawanie oprogramowania
Jest jedna rzecz, której żaden model nie obejmie precyzyjnie, a mianowicie początek projektu. Kiedy program tak naprawdę się rodzi? Zazwyczaj dużo przed napisaniem pierwszej linijki kodu. Najpierw jest mglisty pomysł i pomysłodawca. Jeżeli pomysł wydaje się warty zachodu, to pomysłodawca zaczyna się zastanawiać nad realizacją. Pojawiają się pierwsze detale, wątpliwości - na tym etapie dobrze jest z kimś przedyskutować swoje przemyślenia, najlepiej z paroma osobami. Gdzieś w tych okolicach pojawiają się pierwsze próby implementacji, trochę odbijania się od ścian. Jeżeli do tej pory pomysłodawca się nie zniechęcił, to być może idea będzie już jasna.
Dopiero w tym momencie, kiedy pomysł jest jasny, można myśleć o wciąganiu ludzi do projektu. Dopiero na tym etapie możemy zacząć szukać modelu, według którego będziemy coś robić - kiedy wiemy dokładnie, co chcemy zrobić.
Więc jak ubić pomysł?
- Mam pomysł na fajny program! - Okej, to przygotuj Project Plan i Cost& Time Assesment i mi podeślij. - Aha, to ja już nie mam pomysłu
Żaden wykuwający się pomysł nie wytrzyma nakładu pracy, którego wymaga trzymanie się jakiegokolwiek modelu. Kreatywność nie potrzebuje Project Managera. Kreatywność wymaga elastycznego otoczenia, choćby takiego, gdzie biurka mają kółka.
