Metodyka jako zasób. Inżynieria oprogramowania i Open Practice Library

Kontynuujemy nasze poszukiwania w dziedzinie procesów i metodyk wytwarzania oprogramowania. Wzrost prędkości produkcji software'u oraz popularność tzw. podejścia zwinnego (agile) poskutkowały zalewem wielu przeróżnych wariantów oryginalnego pomysłu spisanego w Manifeście Agile. Oczywiście, zachodzi tu zjawisko podobne, jak w przypadku książek o zarządzaniu – gdyby znano uniwersalną metodę wydajnego zarządzania, nie napisano by na jego temat aż tylu książek.

Jednakże, ciężkie regały podręczników menedżerskich nie są dowodem na to, że nikt nie wie jak zarządzać. Po prostu specyfika każdego miejsca pracy i projektu bywa drastycznie odmienna od reszty, co wymusza ciągłą adaptację metodyki. Nie wszędzie sprawdzi się ten sam kanban lub scaled agile (SAFe), nie wszędzie będzie obowiązywać taka sama definicja pracy poprawnie wykonanej (Definition od Done, DoD). Stąd też poznawanie nowych metodyk pracy jest korzystne i wartościowe, zdecydowanie zaprzeczając poglądowi, że inżynieria oprogramowania jest "pseudonauką".

Nie jest to nowy pomysł, ale zbiór wypracowanych praktyk coraz częściej jest traktowany jako zasób, na równi z innymi. Tworzy to firmową bazę wiedzy. Naturalnym, acz nieco mniej oczywistym następstwem tego podejścia w świecie agile jest zarządzanie praktykami w sposób zbliżony do kodu. Zamiast opasłych, drogich podręczników otrzymujemy w ten sposób repozytorium praktyk, podobnie jak otwarty kod źródłowy jest dostępny na publicznych repozytoriach typu GitHub.

Publiczna dostępność praktyk jako zasobu sprzyja współpracy i wymianie doświadczeń. Celem podtrzymania ducha open source w inicjatywie otwartych praktyk stworzono platformę Open Practice Library, gdzie możliwa jest wymiana i prezentacja wypracowanych praktyk. Podstawową różnicą między klasycznym tworzeniem bazy "firmowych tajemnic", a publikacją praktyk jest świadomość, że istnieje pokaźna część wiedzy, której opublikowanie nie tylko nie zagrozi pozycji firmy i nie wyprodukuje konkurencji, ale wręcz okaże się branżowo korzystne. W świecie ustawicznych braków kadrowych, wpływa to dodanio na wiedzę i kształtuje wartościowe postawy u programistów. Nie wspominając o korzyściach wizerunkowych, przedstawiających firmę jako kontrybutora, a nie kolejny zwykły biznes.

Właśnie o takiej polityce miałem okazję porozmawiać z pracownikami Red Hata podczas mojej wizyty w londyńskim Open Innovation Labs. Nacisk na myślenie open source, rozumiane nie tylko jako publikowanie kodu źródłowego i szum marketingowy, ale faktycznie cała kultura, pozwalająca się dzielić tym, co często jest trzymane pod kluczem zupełnie bez powodu. Red Hat wypracował wiele własnych praktyk i opowiada o nich z dumą. Duża część z nich jest ściśle zorientowana na dzielenie się wiedzą. Nie tylko z innymi firmami, ale także wewnątrz samej organizacji.

Doskonałym przykładem niech będzie, wyśledzony przeze mnie w kącie, kapelusz czarodzieja. Osoba w projekcie, która rozwiąże jakieś nietypowe zagadnienie lub okaże się posiadać wiedzę tajemną niedostępną nikomu innemu (tzw. wysoki bus factor), powinna nosić wspomniany kapelusz aż do momentu, w którym zostanie opracowana metoda podzielenia się wiedzą. Pokazuje to, że tworzenie skomplikowanych, dużych i trudnych rozwiązań nie jest powodem do dumy. Prawidłowym podejściem jest bowiem dbałość o ciągłe zdobywanie wiedzy. Nie tylko przez siebie, ale i przez otoczenie

Biblioteka otwartych praktyk zawiera dziesiątki udokumentowanych metodyk, podzielonych wg. podstawowego rozdziału Mobius: odkrywania, dostarczania oraz możliwości. Zawarte w bibliotece dokumenty dotyczą naprawdę różnych kwestii. Niektóre z nich są związane z poznawaniem klienta i wypracowywaniem metod współpracy (Empathy Mapping).

Inne są związane z tematyką o wiele bardziej pomiarową, jak Priority Sliders, pozwalające implementować priorytety w zadaniach. Nie brakuje również praktyk pozornie mniej innowacyjnych, dostarczających sposoby na optymalizację już stosowanych elementów procesu zwinnego, jak udoskonalanie backlogu (Backlog Refinement).

Dużo praktyk dotyczy zagadnień devopsowych, jak polityka wdrożeń. Nie wszystkie są możliwe do zastosowania w każdym miejscu. Blue Green Deployments jest niezwykle interesującym podejściem, ale nie każdy projekt pozwala na tyle swobody. Niewątpliwie jednak opisana tam metodyka jest poparta czyimś sukcesem. Warto więc okresowo odświeżać swoją wiedzę na temat cudzych rozwiązań devopsowych, niekoniecznie po to, by od razu zacząć je stosować, ale by skonfrontować swoje przyzwyczajenia z cudzą wyobraźnią.

OPL dostarcza także bogaty zbiór materiałów dydaktycznych. Talia kart biblioteki praktyk w przyswajalny sposób pozwala zapoznać się z nowoczesną terminologią inżynierii oprogramowania. Talię można wykorzystywać podczas procesu planowania, powoływać się na zawarte w niej terminy (lub szukać ich przykładów w swojej pracy). Osoby mniej wdrożone w proces zwinny lub uczące się, mogą skorzystać z kodu QR prowadzącego w przypadku każdej definicji do rzetelnego omówienia z przykładami.

Zaletą podziału na karty jest to, że nie trzeba koniecznie implementować wszystkich pojęć z talii. Metodyki zwinne często bywają wprowadzane wskutek panującej mody, na zasadzie "inni tak robią, to my też tak róbmy". Karty pozwalają używać owych terminów jako argumentów, przyspieszających dyskusję i poszerzających wiedzę.

Karty można wypróbować samodzielnie, są dostępne na GitHubie. Oczywiście nie każdy jest podatny na współpracę z rekwizytami. Niemniej owa talia nie jest kolejnym zabawnym gadżetem, o dyskusyjnej przydatności i własnościach alergizujących względem programistów spod szyldu "no fun allowed", twierdzących że radość w pracy jest oznaką braku profesjonalizmu. Rozważam wykorzystanie jej w procesach inżynieryjnych, w których sam biorę udział.

Otwarta kultura pracy oparta nie tylko o kod, ale i o praktyki, będzie coraz popularniejsza. Wiele zwyczajowych, biznesowych granic w IT istnieje dziś bowiem zupełnie bez powodu. Często wynikają one z inercyjnego podejścia, które chroni wszystkie firmowe zasoby, zakładając że każdy wypracowany komponent "zarabia pieniądze". Istotnie tak właśnie jest, ale wysnuwany z tego wniosek, że owymi zasobami nie da się dzielić bez dotkliwej straty jest coraz bardziej błędny.

Red Hatowi dość mocno zależy na przebiciu się z niniejszym przekazem. Nie wszyscy im bowiem wierzą. Fala zwątpienia przybrała tym bardziej po przejęciu firmy przez IBM, kojarzący się wielu z fortecą skostniałych, enterprise'owych rozwiązań, pilnie strzeżonych przez uzbrojonych prawników. Tego typu opinie wydają się być już dziś przesadzone, a sam Red Hat wciąż dość mocno forsuje ideę otwartości, nie tracąc na tym.

Istotnie, w tematyce inżynierii oprogramowania mamy do czynienia z ogromem rozwiązań. Wydaje się, że rozwiązań jest więcej niż problemów, a pewna ich część od czasu do czasu eksploduje (niekoniecznie zasłużenie) jako nowy, "obowiązkowy" trend w organizacji pracy. Biblioteka Open Practice Library może pomóc w wypracowaniu racjonalnych metod rozwoju, acz nie oferuje gotowych przepisów na wszystko. Każdym procesem, źle dobranym lub źle wdrożonym, można sobie zrobić krzywdę.