Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Wspólnota kodu, a proces tworzenia oprogramowania

W teorii

Collective code ownership czyli zbiorowa własność kodu lub współwłasność kodu źródłowego jest jedną z najpopularniejszych technik XP. Dzisiaj właściwie każdy zespól w pewien sposób realizuje tę praktykę przez użycie repozytorium kodu. Ja osobiście nie wyobrażam sobie już życia w inny sposób, ale znam zespoły żyjące jeszcze w zamierzchłych czasach.


Współwłasność kodu źródłowego jest więc prawem każdego członka zespołu do zmiany kodu, nad którym wspólnie pracują. Prawo nie oznacza jedynie dostępu do zasobów na poziomie uprawnień – obejmuje także wszelakie odgórne pozwolenia (zarówno nakazy jak i zakazy) na zmiany w określonych obszarach.  Idealnie nie powinna zatem zajść sytuacja, kiedy konkretna osoba jest odpowiedzialna jedynie za specyficzne dla siebie kwestie.

W praktyce

Osobiście uważam, iż taka zbiorowa własność nie powinna dotyczyć jedynie kodu, powinno się raczej rozważać zbiorową odpowiedzialność projektu,  zespołu czy zadań. Uczestniczyłam w wielu projektach, a każdym z nich charakteryzował się różnym poziomem takiej wspólnoty. Oczywiście możliwość zmiany kodu z repozytorium miał każdy, ale istniało przy tym wiele wskazań dotyczących tego kto powinien gdzie grzebać – czy to znajomość konkretnej technologii (Piotr zawsze zajmuje się pakietami integracji danych, Monika za to zawsze robi raporty), obszaru (ten moduł jest własnością Michała, więc nic tam nie zmieniaj), zaszłości historyczne (Joanna od zawsze zajmowała się persystencją danych) lub podziału zadań. Rzadko jednak można było takie zadania dobierać sobie dowolnie.

Najczęściej pojawiał się jeden schemat – ludzie pracowali nad znanymi sobie rzeczami, nad własnym kodem, we własnej piaskownicy. Jeśli zdarzała się sytuacja wspólnej pracy, polegała ona na dobrowolnym lub nakazanym dopuszczeniu do swego królestwa osób spoza kręgu. Jednak nawet wtedy istniał ktoś kto decydował o tym co się w danym kodzie znajdzie – w końcu ludzie zostali dopuszczeni do królestwa, ale nie do jego opanowania :) Ciekawa rzecz dzieje się w momencie gdy król zachoruje, pójdzie na urlop, czy ogólnie jest nieuchwytny.



Właściwie całkiem niedawno zdarzyło mi się obserwować sytuację, w której członkowie zespołu wykonywali zupełnie odrębne zadania. Podział był całkowity – dotyczył zarówno tego, że nie wybierano sobie zadań, jak i faktu, iż zadania konkretnej osoby zawsze pochodziły z tego samego zakresu. W efekcie nikt nie znał zadań swoich kolegów – nierzadko nawet ich biznesowej wartości. Nadszedł czas gdy szefostwo stwierdziło, iż nie jest to do końca dobre, bo gdy zabraknie jednej z odpowiedzialnych osób, projekt będzie w czarnej… dziurze.

Agile i collective code ownership

Collective code ownership ma jednak polegać na prawdziwej wspólnocie oraz dowolności w wyborze zadań i zmianach kodu tak, by nie trzeba było nikogo pytać o pozwolenie, ani informować nikogo o zmianach. Kod jest wspólny, ale także odpowiedzialność.

Mówi się, że metodyki agile’owe wspierają ideę wspólnoty (pewnie dlatego, iż wywodzi się z XP). Np. blog Pawła dość często opisuje pewną sytuację jako przykład nieoczekiwanych zmian, jakie wprowadza Kanban. W skrócie wygląda ona następująco:
1.    Na początku podjęto decyzję projektową o tym że wspólnoty nie ma, kod został rozdzielony między developerów. Oni sami zajęli się każdy zadaniami ze swojej puli.
2.    W pewnym momencie jednemu developerowi skończyły się zadania z puli, sięgnął więc po to co było w backlogu.
3.    Po pewnym czasie kolejny znalazł się w podobnej sytuacji i w końcu pewnego dnia stała się… wspólnota.

Mogę się oczywiście mylić, bo nie znam sprawy od podszewki, ale opisywana sytuacja wskazuje mi na punkt krytyczny tej historii, a mianowicie fakt skończenia się zadań. Drugim dość zaskakującym elementem jest to, iż ktoś odważył się zajrzeć na podwórko sąsiada. Gratulacje – od decyzji o braku collective code ownership zespól samoczynnie do niego przeszedł.

Nie potrafię jednak w tej zauważyć tu roli samego Kanbana. Powiedziałabym, ze raczej wpływ na nią miała dojrzałość, odpowiedzialność i odwaga programistów. Bardzo często zazdroszczę Pawłowi jego zespołu :) On sam powiedziałby że nie wierzę w ludzi, ja jednak uczestniczyłam w sytuacjach, gdy odgórna decyzją było dzielenie się wiedzą i kodem, a programiści nie tyle niechętnie, co wcale nie sięgali po zadania spoza bezpiecznego i znanego obszaru. Nie wstydzili się nawet potem mówić, że nie robili nic nowego :)

Jeśli już miałabym wybierać metodykę która w pewien sposób promuje opisany w takiej sytuacji rozwój wypadków, byłby to Scrum, a właściwie codzienne spotkania, podczas których członkowie zespołu dzielą się informacjami m. in. na temat tego co zrobili od ostatniego razu. Powoduje to pewne poczucie wstydu jeśli często są w sytuacji, kiedy nie ma dla nich właściwych zadań. Nie można jednak zagwarantować, czy rezultat nie będzie odwrotny – czy takie spowiedzi nie zachęcą managementu po prostu do produkcji większej ilości specjalizowanych zadań. Scrum ponadto wspiera zgłaszanie się do zadań i brak specjalizacji, co w idealnej sytuacji przyczynia się do wyboru zadań, a nie ich przypisywania.


Konkludując, nie sądzę, by collective code ownership był wynikiem zastosowania metodyki (choć niektóre wyraźnie mówią, iż jest on jedną z rekomendowanych praktyk). Dla leniwego (lub rozleniwionego) zespołu takie nakazy niewiele znaczą. Lepiej jest zmotywować zespół i wspierać go w takim postępowaniu. Monitorować sytuację i wyłapywać obszary specjalizacji, niż później zastanawiać się jak ją poprawić. Opłaci się na pewno – wspólna odpowiedzialność to wspólny sukces, a w końcu wspólna radość.
Opublikowane 7 października 2011 16:46 przez fusion

Komentarze:

10 października 2011 14:53 by Pawel Brodzinski

# re: Wspólnota kodu, a proces tworzenia oprogramowania

Nie wierzysz w ludzi :)

Uzupełniając naszą historię: zasługą Kanbana było zdefiniowanie pewnych reguł, w szczególności dotyczących tego w jaki sposób dobieramy zadania z backloga.

To nie do końca tak, że brakło określonych zadań w backlogu i dlatego pojawiły się sytuacje, w których zaczęliśmy brać zadania z nie naszych obszarów. Backlog był pełny takich funkcjonalności. Tyle że zdecydowaliśmy, że zawsze zaczyamy tworzyć zadanie, które w danej chwili jest najważniejsze.

Jasne, w zasadzie każdy zespół powie to samo: chcemy realizować zadania, które w danej chwili są najważniejsze lub najpilniejsze. Ciekawą kwestią jest natomiast jak wiele z tych zespołów rzeczywiście pracuje w taki sposób. Jak często dobór zadań nie zależy od ich wagi czy pilności a właśnie od tego, który obszar aplikacji dany developer zna czy które zadanie będzie mu zrobić najłatwiej.

Rolą Kanbana, przynajmniej w naszym przypadku, było zwizualizowanie, że nie zawsze działamy tak jak wydaje się nam, że działamy. Masz rację twierdząc że decyzja o collective code ownership to była decyzja ludzi a nie coś co jest w jakiś sposób wymuszone czy zapisane w metodyce z której korzystaliśmy. Nie zmienia to faktu, że nadal dużą część zasłu przypisuję Kanbanowi, jako katalizatorowi całego procesu.

I jeszcze jedna rzecz, o której wcześniej w sposób świadomy nie pomyślałem - zmiana którą opisałem była o tyle łatwiejsza że za każdym razem decyzja dotyczyła tylko tego jednego zadania, a nie całości kodu. To tylko kilka klas, kawałek modułu, maleńka część całej aplikacji. Innymi słowy cały wysiłek był rozbity na długi okres czasu.

Co ciekawe gdybyśmy podjęli decyzję o włączeniu collective code ownership do zestawu naszych praktyk na początku projektu to wysiłek byłby rozłożony podobnie - małymi kawałkami na cały okres trwania projektu, a jednak nie podjęliśmy wyzwania.

Na pewno duch eksperymentowania który jest nieodłączną częścią Kanbana był tu dla nas wentylem bezpieczeństwa - jeśli collective code ownership nie będzie dla nas działał, to po prostu zmienimy zasady rządzące backlogiem i wrócimy do tego co było. To także jest kwestia o której nie należy zapominać. Teraz na daną historię patrzymy znając jej koniec, więc łatwo nam wyciągać wnioski - wnioski, do których nie doszlibyśmy będąc w jej trakcie.

10 października 2011 20:40 by fusion

# re: Wspólnota kodu, a proces tworzenia oprogramowania

Nie spodziewałam się aż takiego rozwinięcia, ale dziękuję - teraz wszystko jest jaśniejsze :)

Jeśli chodzi o mój "brak wiary w ludzi", to niestety w pewnej mierze spowodowany jest doświadczeniem. Byłam w projektach gdzie collective code ownership był nakazany, zakazany, gdy metodyka faworyzowała własne zadania, najważniejsze i losowe. Nigdy nie zaznałam jednak prawdziwej wspólnoty. Zazdroszczę zespołom, którym się to udało :)

Komentarze anonimowe wyłączone