Cold Fusion

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ść.

TFS a proces tworzenia oprogramowania

W świecie projektów .Netowych dość często spotykam się z sytuacją, gdzie intensywnie używane jest Visual Studio, natomiast rola TFS ogranicza się jedynie do kontroli wersji. Co prawda od czasu do czasu ktoś stworzy Taska lub Buga, w porywach nawet dołączy do niego związany kod, jednak nie ma to wiele wspólnego z ogólnie obowiązujacym procesem (inna sprawa czy w ogóle obowiązuje jakiś proces :)).
A jednak nazwa Team Foundation Server wskazuje na pewien zakres odpowiedzialności w pracy zepołu.
Skąd więc ta niechęć? Czyżby TFS nie był narzędziem prostym, łatwym i przyjemnym? A może brakuje mu czegoś, co uniemożliwia wdrożenie specyficznych dla projektu aspektów?
Chyba nie jest tak źle, skoro równocześnie istnieje tyle firm i zespołów niemal w pełni wykorzystujacych ofertę TFSa.
Może problem tkwi w niedokładnej eksploracji i braku świadomości o jego możliwościach. Postaram się pokazać zalążek tych możliwości oraz tego, co można zrobić mając gotowy projekt procesu.

A więc niech stanie sie proces...

Na potrzeby przykładu będę operować jedynie na TFSowych Taskach, ale proponowane rozwiązanie może być zastosowane dla dowolnego Work Itema włączając w to nowe typy zdefiniowane przez zespół.

Załóżmy, że chcemy zamodelować w TFSie następujący proces zmiany stanu zadań:

Oprócz tego zadanie powinno mieć dodatkowe pole oznaczające kod (mający ogromne znaczenie w naszym projekcie :)), dla pokazania łatwości zmiany kształtu i wyglądu zadania.

Dostosowanie do naszych potrzeb oznacza również dodatkowe ograniczenia:
- osoba która stworzyła zadanie nie może go aktywować,
- implementowanie zadania może byc przypisane jedynie do osoby z grupy Developers,
- wdrażanie zadania może być przypisanie jedynie do osoby z grupy Deployers, ale nie może to być ta sama osoba, która zaimplementowała zadanie,
- zamknąć zadanie może jedynie osoba która je stworzyła.

Wdrażanie zmian

Aby zmienić definicję Taska należy najpierw ściągnąć jego definicję z servera. Robimy to dzięki komendzie (Visual Studio Command Prompt):

witadmin exportwitd /collection:<ServerAddress> /p:<ProjectName> /n:Task /f:<DiskLocation>\<filename>.xml

Dzięki temu w miejscu <DiskLocation>\<filename>.xml powstanie plik z definicją, na której od tej pory będziemy pracować. Chcąc zmieniać definicję Taska można zaimportować na serwer nową definicję. Można również stworzyć swój własny typ przez wprowadzenie nowej nazwy w tagu:
<WORKITEMTYPE name="Special Task">

Import definicji na serwer odbywa sie przez użycie nastepujacej instrukcji:

witadmin importwitd /collection:<ServerAddress> /p:<ProjectName> /f:<DiskLocation>\<filename>.xml

Zmiana layoutu

Dodatkowe pole kodu w definicji Taska dodajemy przez wstawienie do <FIELDS> następującego wpisu:

<FIELD name="ProjectCode" refname="MyCompany.MyProcess.ProjectCode" type="String">
    <HELPTEXT>Describes the project code.</HELPTEXT>
</FIELD>

Widoczność i edytowalność pola uzmożliwia xml, wstawiony w wybranym przez nas miejscu w <FORM><Layout>:

<Control Type="FieldControl" FieldName="MyCompany.MyProcess.ProjectCode" Label="Project Code" LabelPosition="Left" />

Oczywiście możemy dodawać pola o różnych typach, edytowane w różnych kontrolkach. Podany przeze mnie przykład obejmuje sytuację najprostszą: string i textbox.

Efekt widać po imporcie definicji:



Modelowanie procesu

Aby w procesie zmian stanu zadania pojawiły się odpowiednie wartości, należy wprowadzić zmiany w tagach <WORKFLOW><STATES> i <WORKFLOW><TRANSITIONS>.

Definicje stanów (<WORKFLOW><STATES>):

        <STATE value="Unapproved">
        </STATE>
        <STATE  value="Active">
        </STATE>
        <STATE value="Implemented">
        </STATE>
        <STATE value="Deployed">
        </STATE>
        <STATE value="Closed">
        </STATE>

Przejścia między stanami natomiast (<WORKFLOW><TRANSITIONS>):

        <TRANSITION from="Unapproved" to="Active">

Przedstawiany przeze mnie proces jest prosty i nie zawiera powrotów ani pętli, ale można to z powodzeniem zamodelować.

Przypisywanie osób i ograniczanie dostępu

A teraz najtrudniejsza część - ograniczenia dostępu:

(1) Osoba, która stworzyła zadanie nie może go aktywować.

Najpierw dodamy nowe pole, które będzie przechowywać informację o tym kto stworzył zadanie:

<FIELD name="PreparedBy" refname="MyCompany.MyProcess.PreparedBy" type="String">
        <HELPTEXT>Person that created the task.</HELPTEXT>
</FIELD>

Pole to jest wypełniane obecnym użytkownikiem w pierwszej tranzycji, czyli gdy zadanie jest tworzone:

<TRANSITION from="" to="Unapproved">
        ...  
    <FIELDS>
            <FIELD refname="MyCompany.MyProcess.PreparedBy">
              <COPY from="currentuser" />
            </FIELD>
            ...
    </FIELDS>
</TRANSITION>

W tranzycji z "Unapproved" do "Active" do pola "ActivatedBy" wstawiamy ograniczenie:

<FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
   <ALLOWEXISTINGVALUE />
   <COPY from="currentuser" />
   <NOTSAMEAS field="MyCompany.MyProcess.PreparedBy"/>
   <VALIDUSER />
   <REQUIRED />
</FIELD>

(2) Implementowanie zadania może byc przypisane jedynie do osoby z grupy Developers.

Po pierwsze prawo do dokonania tranzycji mają jedynie developerzy:
<TRANSITION from="Active" to="Implemented" for="[Project]\Developers">

Po drugie lista osób możliwych do przypisania powinna być róznież ograniczona:
          <FIELDS>
            <FIELD refname="System.AssignedTo">
              <ALLOWEDVALUES expanditems="true">
                <LISTITEM value="[Project]\Developers" />
              </ALLOWEDVALUES>
              <COPY from="currentuser" />
            </FIELD>
          </FIELDS>

Dodatkowo dodajemy do Taska pole, które przyda sie w nastepnym kroku:
        <FIELD refname="MyCompany.MyProcess.ImplementedBy">
              <COPY from="currentuser" />
        </FIELD>


(3) Wdrażanie zadania może być przypisanie jedynie do osoby z grupy Deployers, ale nie może to byc ta sama osoba która zaimplementowała zadanie.

Podobnie jak wcześniej ograniczamy dostęp w tranzycji:
<TRANSITION from="Implemented" to="Deployed" for="[Project]\Deployers">

Pola dla tranzycji wyglądają teraz następująco:
          <FIELDS>
            <FIELD refname="System.AssignedTo">
              <ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
                <LISTITEM value="[Project]\DeploymentAdministrators" />
              </ALLOWEDVALUES>
              <COPY from="currentuser" />
            </FIELD>
            <FIELD refname="MyCompany.MyProcess.DeployedBy">
              <COPY from="currentuser" />
              <NOTSAMEAS field="MyCompany.MyProcess.ImplementedBy"/>
            </FIELD>
          </FIELDS>


(4) Zamknąć zadanie może tylko osoba która je stworzyła.

Tutaj przy się pewna sztuczka ponieważ nie mamy do dyspozycji znacznika typu <SAMEAS>.
Definiujemy więc pole które jest oznaczone jako FROZEN:

<FIELD name="ClosedByValidation" refname="MyCompany.MyProcess.ClosedByValidation" type="String">
        <HELPTEXT>Person that closed the task.</HELPTEXT>
        <FROZEN/>
</FIELD>

A do wnetrza obydwu stanów: Unapproved i Closed wrzucamy nastepujacy zapis:
    <FIELDS>
            <FIELD refname="MyCompany.MyProcess.ClosedByValidation">
              <COPY from="currentuser" />
            </FIELD>
    </FIELDS>

Powoduje to sytuację, w której stworzenie zadania zapisaniem obecnego uzytkownika. Każda następna próba zapisu spowoduje błąd jeśli wartość nie będzie zgodna z juz istniejącą, co spowoduje bład:


To tylko kilka pomysłów... Mam nadzieję, że przydadzą się w modelowaniu waszych własnych procesów :)

Dwa datasety w raporcie SSRS

Niedawno w trakcie tworzenia raportu SSRS natknęłam się na problem umieszczenia informacji z dwóch datasetów w jednym tablixie.

W systemie głównym przechowujemy pewne informacje. Dla uproszczenia niech to będzie tabela Entity:

Procedury bezpieczeństwa nie pozwalają na zmiany wartości 'SomeInformation' w bazie danych przez prostą edycję wartości. Zmiany takie muszą przejść skomplikowany proces zaczynający się od wniosku zmiany, a kończący się na zmianę danych w głównym systemie. Zmianami dotyczącymi obiektów Entity zajmuje sie drugi system, z osobnym serwerem aplikacji i - by bardziej skomplikować sprawę - z osobną bazą danych.

Wnioski zmiany trzymane są w tabeli ChageRequest:

Mając w głównym systemie dane:

oraz wnioski o zmiany w systemie drugim:

chcemy wyprodukować raport porównujący wnioski o zmiany z oryginalnymi wartościami:

I chcemy taki raport stworzyć za pomocą SSRS.

Teraz pytanie czy SSRS umożliwia wrzucenie do tabeli danych z dwóch różnych datasetów?
Element tablix może mieć przypisany tylko jeden dataset, ale raporty oferują przeróżne funkcje które pozwalają na wykorzystanie danych przez jawne podanie nazwy innego datasetu (np. First, Last, Max). Jednak nie do końca o to chodzi - nas interesuje join tych dwóch datasetów, a nie proste wyciągnięcie wartości.

Przeszukałam internet i najczęściej pojawiającą się radą były UNIONY tych dwóch tabel, oraz joiny między tabelami. Problem pojawia się gdy potrzebujemy joina po tabelach znajdujących sie w dwóch równych bazach danych na dwóch różnych serwerach.
Chcemy więc mieć możliwość stworzenia dwóch datasetów:

dsChangeRequests - select * from ChangeRequestTable
dsEntities - select * from EntityTable

Następnie ustalamy dane z dsChangeRequest - nic prostszego:

CodeName:       OldValue:        NewValue:       OriginalValue:
[CodeName]      [OldValue]         [Newvalue]        Expr

W kolumnie 'OriginalValue' powinno się znaleźć wyrażenie robiące cos w rodzaju:
Expr = select SomeInformation from dsEntities where EntityName = CodeName

Nie będzie to może super szybkie, ale z punktu widzenia danych jest to właśnie to, czego szukamy. A może jest lepszy sposób... ? - czekam na propozycje.

W końcu, po wielu bojach dotarłam do oczekiwanego rozwiązania :) :
Expr = Lookup(Fields!CodeName.Value, Fields!EntityName.Value, Fields!SomeInformation.Value, "dsEntities")

Sztuka dawania feedbacku

Szkolenia miękkie i pozytywny feedback
Zauważyłam w ostatnim czasie wysyp tzw. szkoleń miękkich. Sama w nich uczestniczę, moi współpracownicy, wielu krewnych i znajomych królika... W trakcie takich szkoleń często przewijają się tematy managementu, komunikacji i pozytywnej informacji zwrotnej.

To, iż ostatnia kwestia znajduje sie w agendzie szkoleń powodowane jest oczywiście faktem, iż ludzie chętniej słyszą o sobie dobre rzeczy. Pozytywny feedback ma na celu znalezienie dobrego we wszystkim, co oferuje pracownik, odniesienie się do pozytywów i oczywiście łagodne przekazanie tej informacji. Kierownicy nie chcą przecież nikogo stresować, a optymizm jest podobno zaraźliwy.

Natomiast rzeczywistość...
Jednak moim skromnym zdaniem nie jest prawdą, iż jedyny feedback jaki dostają pracownicy jest negatywny. Postawiłabym dużo pieniędzy na stwierdzenie, iż najczęściej padającymi zdaniami w pracy biurowej (oczywiście prócz  przekleństw) są sentencje w stylu: "Good job". Pytanie czy słowa te są szczere i poparte konkretnymi osiągnięciami, czy może ich celem jest jedynie podniesienie morale i stworzenie dobrej atmosfery.

Innym aspektem jest fakt, iż pracownicy dostają informację zwrotną najczęściej (jeśli w ogóle) w formie rocznego podsumowania. Oznacza to, iż dowiadują się o rozdźwięku między własną oceną pracy a oceną managera dopiero po pewnym czasie. Nie trzeba nawet wspominać, że pracownik nie jest przygotowany na zarzuty, gdyż minął rok, i do tej pory nikt mu nie mowił, że coś jest nie tak. Pracodawca z kolei rzadko kiedy ma w zanadrzu jakieś merytoryczne argumenty, czy konkretne wpadki. Nie zapisuje ich w ciągu roku, ma po swojej stronie jedynie przeczucie, np. że nie do końca dobrze ocenia pracę członka swojego zespołu.

Moja rada dla managerów
Proszę apeluje: zacznijcie od dawania jakiegokolwiek regularnego feedbacku. Zacznijcie od częstego oceniania pracy i równie częstego informowania o wynikach tej oceny - niezależnie od tego czy jest ona pozytywna czy negatywna. Nie skaczcie od razu na głęboką wodę, chcąc na siłę znaleźć coś dobrego. Jeśli chcecie być świetnymi managerami, świetnymi szefami, nauczcie się tego razem ze swoimi pracownikami.

Początkowo nie bawcie się w całe koło zabezpieczania relacji, konstruktywną krytykę, komunikaty ja, czy eufemizmy. Skupcie się na tym by informacja była i by ją przekazać. Niech to początkowo będzie nawet marudzenie i brak argumentów merytorycznych, a jedynie sygnał: "OK", "Nie OK". To wystarczy by pracownik dowiedział się jakie macie odczucie co do jego pracy. Wtedy może sam do was przyjść i zapytać co jest nie tak, sprawa potoczy sie dalej. Nad formą możecie popracować następnym razem.

Nie zakładajcie, że jeśli ktoś ciągle cos chrzani, to o tym wie i robi tak wciąż tylko dlatego, by was zdenerwować. Poinformujcie o tym co jest źle i ile jest jeszcze szans na pomyłki. Jest duże prawdopodobieństwo, że pracownik nie zdaje sobie sprawy z popełnianych błędów, bo... nie ma informacji zwrotnej. Z negatywnych doświadczeń płynie nauka. Nie uczymy się tak wiele z sytuacji, gdy wszystko jest w porządku.

Oczywiście feedback pozytywny również jest ważny, ale tylko wtedy, gdy ma on pokrycie w rzeczywistości. Dla inteligentnego pracownika bez kompleksów ciągłe powtarzanie przez szefa słów: "Good job" odnosi odwrotny skutek, niż zakładane podniesione morale. A jeśli zakładacie brak inteligencji lub kompleksy u pracownika, to jak to świadczy o was managerach?

The Big Bang Theory – filmowa historia transformacji

X-Men Geneza: Wolverine

Dawno, dawno temu była sobie firma produkująca oprogramowanie. Firma była mała, z młodym zarządem, młodymi programistami. Młodości dodawało niewielkie doświadczenie zarówno założycieli jak i zatrudnianych osób. Wiek dziecięcy firmy skutkował łączeniem ról, wszyscy pisali kod, rozmawiali z klientami, dokonywali analizy funkcjonalnej. Firma nie posiadała również jasnej ścieżki kariery, nic dziwnego więc, że każdy robił to co czuł, że powinno być robione. Nie było jawnego podziału odpowiedzialności.

Z klientami rozmawiano przez telefon, także osobiście, gdyż często przyjeżdżali by zobaczyć efekt końcowy produktów z jakimi zmagali się pracownicy firmy.

X2 (Matrix Rewolucje)

W pewnym momencie ktoś postanowił: Takie podejście nie jest profesjonalne!. Powinniśmy usprawnić nasze procesy, powinniśmy je najpierw stworzyć.

Zebrało się grono decyzyjnych osób i przedstawiło swoje postulaty.

• Nie może tak być, że każdy robi co chce – stwórzmy opisy stanowisk z przypisanymi odpowiedzialnościami.

I stało sie: Stworzono stanowiska kierowników, dyrektorów, oraz podział technicznych stanowisk na kilka stopni...

• Nie może tak być, że analizą wymagań zajmuje się szary programista, a kierowaniem projektem kierownik zespołu.

I stało się: Stworzono stanowiska odpowiedzialne za analizę wymagań i kierowanie projektem...

• Nie może tak być, ze nikt nie kontroluje jakości oprogramowania.

I stało się: Stworzono dział QA...

X-Men (Matrix Reaktywacja)

Fantastycznie! Teraz każdy wie co ma robić. Firma dorosła, stała się bardzo profesjonalna. - krzyczano na lewo i prawo.

Czy aby na pewno?

Otóż proces tworzenia oprogramowania w skrócie zaczął wyglądać następująco: Analiza -> Projektowanie -> Implementacja -> Testowanie
A nad nim czuwa kierownik projektu…

Klient nie zadzwoni już do programisty aby zapytać o postępy, umówi się raczej na formalne spotkanie, gdzie kierownik projektu lub tez osoba odpowiedzialna za sprzedaż przedstawi mu piękną prezentację.
Oczywiście sporadycznie pojawiły się głosy: Dodajmy do tego procesu pętlę (iteracje), dostosujmy go na potrzeby code review, ale powyższa forma mocno się zakorzeniła.

Nie będę się rozwodzić nad tym czy i dlaczego waterfall nie działa, lub jak ważny w trakcie trwania projektu jest udział klienta. Chodzi o sam fakt, iż mała samoorganizujaca się firma realizująca właściwie wspaniały agile’owy proces cofnęła się o epokę (mówię o epokach umownych dotyczących procesu tworzenia oprogramowania) nawet tego nie zauważając. I to w imię rozwoju, jakości i profesjonalizmu.

Wszelakie wypowiedzi agile’owych ewangelistów przekonują, iż proces transformacji podejścia do prowadzenia projektów odbywa się wg schematu: formal -> agile. Niemniej jednak nie jest sytuacją rzadką odwrotny jej kierunek (dlatego tytuły filmów występują w tym odwróconym kierunku). W końcu profesjonalizm kojarzy się z procesami – miękkie aspekty takie się nie wydają. Często niedoceniane są sprawy załatwiane nieoficjalnie, czy też rozluźnienia procesów kojarzone z samym agile’m.

X-Men: Ostatni Bastion

Problemem stają sie w takiej sytuacji m. in. ścieżki kariery. Co jeśli będąc programistą (wg stanowiska) jestem dodatkowo (praktycznie) testerem, albo analitykiem? Czy powinnam robić to wolontarialnie, jeśli nikt mi za to nie płaci? Pewnie dostanę pełno głosów, że tak, ale uwaga – to pytanie jest retoryczne. Chodzi mi o sam fakt występowania takich dylematów.

Właściwie zgadzam się ze stwierdzeniem, że to developerzy powinni zajmować się strona biznesową tworzonych aplikacji. Nie uważam też za dobry pomysł wydzielanie specjalnych działów analityków, kierowników projektów, testerów – stoi to w sprzeczności z zasada samoorganizacji agile’owych zespołów, ale przede wszystkim doprowadza do sytuacji, gdy konkretne osoby stoją przed wyborem lojalności wobec własnej ścieżki kariery i szefa swojego działu oraz projektu, w jakim uczestniczą. Takie osoby nie są częścią zespołu, albo ten pobyt jest mocno utrudniony.

Dodatkowo jeśli firma posiada takie specjalizowane działy, skazuje się na konkretną metodykę. Zamykamy jej (lub znów bardzo utrudniamy) zastosowanie np. scruma, gdzie rola kierownika projektu nie istnieje.
Co jeśli nagle przyjdzie moda/ochota na jeszcze inną metodykę? Zaczniemy zmieniać strukturę firmy od nowa?

Oczywiście uważam, że firma wręcz powinna się powiększać i rozwijać, a przez to również zmieniać. Również procesy nie są złe same w sobie. Muszą jakieś istnieć, bo inaczej zrobi się straszny bałagan i nikt nie będzie w stanie pracować. Ale standaryzacja wszystkiego łącznie z tym jak powinny być prowadzone projekty nie jest dobrym pomysłem. Co więcej, procesy w większej firmie są potrzebne, gdyż o ile mała świetnie radzi sobie z samoorganizacja - w większej nie jest to wcale proste.
Ostatnimi czasy pojawiło się wiele głosów mówiących o tym, ze nowoczesny management musi być bardziej nastawiony na to, by stworzyć takie środowisko pracy. Powinno się raczej pozwalać ludziom pracować na ich własnych warunkach (servant leadership) niż kierować tym co i w jaki sposób robią. Zmiany powinny więc dotyczyć podejścia do nowoczesnego managementu niż zmuszania deweloperów do pracy przy ustalonych przez "wyższe władze" zasadach.

Kilka głupich wpadek...

Nawiązując do postu Procenta o głupich rzeczach podczas kodowania chciałam dodać swoje przykłady, które czasem (często ?) doprowadzają mnie do szału. I żeby nie zrozumieć mnie źle – zwykle jestem zła na siebie, ale chyba równocześnie równie mocno na Microsoft.
Let me begin…

Gdzie jest tekst z TextBox’a?

Problem o którym zaraz napiszę zwrócił moją uwagę głównie z powodu, iż zdarza mi się nader często i wciąż zapominam czym jest spowodowany. Generalnie sama już nie wiem czy ciągle występuje z powodu mojej głupoty (w końcu skoro znam powód i rozwiązanie to powinnam o nim pamiętać, a nie wciąż popełniać te same błędy) czy mojego braku umiejętności zaakceptowania takiego stanu spraw.
Ale do rzeczy…
Buduję sobie piękną aplikację ASP.Net. Używam standardowych kontrolek. Powiedzmy ze wyświetlam listę wydatków:



Sens akceptacji to zgłoszenie wydatków (choćby jednego). Jak to najłatwiej sprawdzić? Oczywiście sprawdzając czy ich suma jest większa od zera. Przy wpisywaniu wydatków wykonywana jest funkcja JavaScript sumująca je do pola ‘Suma:’. Walidacja wartości może być wykonana przez kod:

        protected bool ValidateSum()
        {
            if (!string.IsNullOrEmpty(sum.Text))
            {
                int sumValue;
                int.TryParse(sum.Text, out sumValue);
                return sumValue > 0;
            }
            else
            {
                return false;
            }
        }

Dlaczego więc dostaję błąd walidacji? Suma moich wydatków to 105.3. Skąd komunikat ‘Aby zaakceptować  musisz zgłosić wydatki’?
Wbrew zasadzie ‘nie debugguj, pomyśl’, ja jednak zaczęłam debuggować. No i okazało się, że…



… mimo iż widzę jak byk, ze na stronie wartość to „105.3”, pole nie posiada wartości property .Text. Why Leo, why? Tak wiem – można się kłócić, że to z powodu mojej głupoty, że powinnam wiedzieć, że TextBoxy o ustawionej wartości ReadOnly na „true” nie mają ustawionej wartości Text… Powinnam, wiem, ale prawie nigdy o tym nie pamiętam.

Dlaczego? Bo to nie ma dla mnie żadnego sensu – oczywiście mówię tu o punkcie widzenia użytkownika takiej kontrolki. Być może z perspektywy jej implementacji jest to sprawa oczywista, ale tego nie wiem.
Skąd ty czytelniku miałeś wiedzieć, że kontrolka ma wartość ReadOnly ustawioną na „true”? Pewnie trochę z doświadczenia z podobną sytuacją, albo z faktu, iż pole sumujące nie powinno być edytowalne. Anyway – ja niemal nigdy nie pamiętam, że przeżyłam już taką sytuację 100 razy. Może napisanie o tym w notce coś zmieni przynajmniej dla mnie.

BTW – ma ktoś jakieś sensowne lekarstwo na ReadOnly?

Execu dlaczego się nie uruchamiasz?

Pewnego pięknego dnia uruchomiłam sobie plik.exe. Robiłam to od kilku miesięcy kilka razy dziennie, a tym razem dostałam komunikat:



MyExec uruchamiał zdalnie aplikację znajdującą się na serwerze testowym, więc pomyślałam w pierwszej chwili, że ktoś bawił się tam uprawnieniami (w końcu komunikat wygląda tak jakby był jakiś problem z bezpieczeństwem). Nie znam się na tym kompletnie, więc w końcu zaczęłam google’ać. To również nie przyniosło pożądanego skutku – najczęstsza rada dotyczyła zmiany Policy level. Nie muszę chyba dodawać jak mało pomocne się to okazywało.
Na szczęście jeden post mnie natchnął i doprowadził do rozwiązania. Chodziło mianowicie o ustawienie opcji uruchamiania mojego programu jako ‘Run as administrator’. Powinnam dodać, że pracuję na… Windows 7?

Czy komentarze to przeżytek?

A' propos tematu komentarzy postu Szymona i uwag do tego postu, chciałam dodać swoje trzy grosze...

Nie tak dawno temu byłam świadkiem kształtowania się idei i powstawania zbioru reużywalnych bibliotek. Przy okazji tej inicjatywy podjętych zostało kilka decyzji. Czy chodziło o to by w końcu było porządnie? - nie wiem. Na pewno rozpoznawano i zaproponowano wiele technologii, nowych i starych podejść do tworzenia oprogramowania oraz metodyk, ktore nie istniały w szeroko pojętym użyciu.

Pomijając fakt sensowności budowania własnych bibliotek, inicjatywa spowodowała, iż stało się wiele dobrego, np. w końcu zaczęto używać integration buildów, developerzy uslyszeli w końcu i nawet byli skłaniani do pisania testów. Ale sprawa, o której chcę napisać dotyczy decyzji o wymagalności spełniania reguł sprawdzających napisany kod. Zwłaszcza jedna kwestia wydawała się dość kontrowersyjna - reguły wymagalności istnienia komentarzy.

W związku z tym rozgorzała dyskusja, w trakcie której ścierały się dwa obozy. Podobno chodziło im o to samo - o większą czytelność kodu. Oto argumenty obu stron:
Team 1: Komentarze wprowadzają wyjaśnienia do kodu, więc są nie tylko przydatne, ale również niezbędne. Jeśli kod jest źle napisany - musi być skomentowany lub poprawiony. Jeśli kod jest napisany dobrze - w komentarz powinien po krótce opisywać odpowiedzialność klasy, to co robią metody, jakie przyjmują argumenty, jakie pola i wlasności posiada klasa.
Team 2: Potrzeba komentowania kodu wskazuje, że jest on źle napisany. Zamiast komentarzy piszmy kod dobrze.

IMHO  żadna z tych skrajnych opinii nie jest do końca słuszna. Zgodzę sie oczywiście, że w idealnym świecie, z idealnym kodem (i z idealnym leżakiem dla mnie na idealnej plaży w Santa Monica) komentarze są zbędne. Zgodzę się, że idealnie napisany kod ich nie potrzebuje, ale... czy ktoś kiedyś widział idealny kod? Nie twierdzę jednak, iż komentarze nie są potrzebne, by wyjaśnić to, co nie jest jasne. No i oczywiście w całej aferze komentarzowej chodziło również o mozliwość generowania dokumentacji.
 
I tak wracamy do idei bibliotek firmowych... Osoby podejmujące decyzje należały do pierwszego obozu, więc reguły nakazywały by istniały komentarze dla każdej klasy, dla każdej metody, dla każdej własności i dla każdego pola klasy. Co z tego wyniknęło prócz kłótni? Zobaczmy...

Komentowanie wszystkiego

Ciekawa sprawa - komentarze dobrze napisanego kodu są nie tyle złe, co dość zabawne. Oto kilka znalezionych przykładów:

/// <summary>
/// Klasa reprezentująca atrybut.
/// </summary>
public class Attribute
{
 ...
   /// <summary>
   /// Dodaje atrybut.
   /// </summary>
   /// <param name="attribute">Atrybut.</param>
   public void AddAttribute(Attribute attribute)
   {
      ...
   }
   ...
   /// <sumary>
   /// Nazwa atrybutu.
   /// </sumary>
   public string AttributeName
   {
    get;set;
   }
}

Przydatne te komentarze, nieprawdaż?
Można sobie wyobrazić ile roboty jest z ich pisaniem - dokładnie, tyle ile wynosi wymyślenie i napisanie komentowanego właśnie kodu. Efekt to zero przydatnych informacji i trochę smiechu przy czytaniu. Oczywiście jeszcze zabawniej byłoby gdyby na dodatek zarówno nazewnictwo kodu jak i komentarze były w języku angielskim - w tej sytuacji mamy niemalże translator :D
W tym miejscu warto wspomnieć o kolejnej regule która sprawdzała istnienie kropki na końcu komentarza, więc aby zdanie nie posiadało jednego tylko słowa, niektórzy deweloperzy zmieniali "Atrybut." na "Dodawany atrybut." :D Zadziwiało mnie w imię czego występowało takie poświęcenie i jak niedoceniani byli ci cisi bohaterowie :)

Komentowanie złego kodu
Jeśli chodzi o metody, które wymagają komentarzy (dla zrozumienia tego, co robią) radziłabym mieć ciągle z tyłu głowy dwie sprawy. Po pierwsze należy się zastanowić czy komentowanie kodu nie zajmie nam więcej niż jego poprawienie, a po drugie (jeśli odpowiedź na pierwsze pytanie to 'nie' i jednak decydujemy się na komentarz) zaplanować ten refaktoring w przyszłości.
Jesli wyjaśnienie dotyczy zawartosci metody, opisu klasy, ktora zostala napisana w niezrozumiały sposob, to kilka zdań nie zaszkodzi, a moze pomóc. Jesli natomiast komentarz dotyczy tego by po krótce przedstawić nagłówek, to moze warto zastanowić się nad zmianą jej nazwy na bardziej sugestywną - to może wystarczyć.

Muszę jeszcze dodatkowo ostrzec przed tym, by zbytnio nie ufać narzędziom. Sprawdzały one jedynie istnienie komentarzy, które nagminnie wystepowały w nastepujacych formach:
- Nie mam czasu komentować.
- Póżniej to skomentuję.
- Tralalalala...
- Itd.
Prawdę mówiąc widząc to nie zdziwilabym sie gdyby gdzieś tam istniały jakies nieprzyzwoite slowa, skoro nikt nie bał się w ten sposób spelniać narzuconych wymagań :D

Komentowanie metod w klasach dziedziczących
Kolejny problem pojawił się również z winy narzędzia. Otóż klasa implementujaca interfejs (lub dziedzicząca metody innej klasy) nie dziedziczyla dokumentacji znajdującej się w komentarzach. Aby więc spelnić wymagania nalezało skopiować te komentarze lub uzyc R# (co sprowadza sie do rozwiazania pierwszego). Osobiście odczułam to boleśnie, bo akurat w moim przypadku sprowadzalo sie to do wielu godzin bezsensownej pracy.

Najśmieszniejsze, że jednym z zamysłów budowy bibliotek było chowanie wszystkiego za interfejsami. Pomysł zacny - tworzymy swoistego rodzaju adaptery, natomiast w aplikacji konfigurujemy tylko której implementacji uzywamy i voila, wszystko ma hulać.
Dokumentacja jaką widzi użytkownik biblioteki to jedynie dokumentacja interfejsu. Teoretycznie nie powinien nigdy używać klas implementujących, a juz na pewno nie operatora new :D Tak wiec... po co mu ta odziedziczona dokumentacja?

Konkludując - błędem jest zakładanie, że kod nie potrzebuje komentarzy, ale jeszcze większą pomyłke robi się zmuszając do komentowania wszystkiego. Jest to strata czasu, a efekty są marne. Same komentarze w takiej sytuacji nie ułatwiają zrozumienia niczego, nawet pomijając fakt, że ludzie w sytuacji kiedy się ich do czegoś zmusza, nie zrobią ich porządnie. W czasach intellisense użytkownicy nie czytają dokumentacji - liczą na sugestywne nazwy klas, metod i własności. To właśnie poprawia jakość kodu i dostatecznie wyjaśnia im jak używać danej biblioteki.
Komentarze nagłówkowe to przeżytek. Komentarze wewnątrz metod natomiast to ryzykowna sprawa... Mogą pomoc w zrozumieniu zawartości, ale najczesciej są zrozumiale jedynie dla autora, na dodatek w momencie ich tworzenia. Z biegiem czasu tracą na aktualnosci, inni boją sie je usunać i powstaje swoistego rodzaju bałagan.
Apeluję więc by developerzy jeśli już piszą konmentarze odnosili się do nich jak do kodu. Mimo braku automatycznego sprawdzania ich składni, by pisali je dobrze, zrozumiale oraz tak, by były one naprawdę pomocne. W innym wypadku nie mają większego sensu.

UMLowy profesjonalizm

Niedawno zostałam poproszona o przeszkolenie zespołu programistów w temacie notacji UML.
Niestety przed szkoleniem nie byłam w stanie zdobyć wielu informacji dotyczących oczekiwań poza generalnym stwierdzeniem, iż stan wiedzy słuchaczy na temat UMLa jest zróżnicowany - niektórzy nie wiedzą kiedy stosować jakie diagramy, inni nie znają nawet podstaw notacji. Wiedzę należało usystematyzować tak, by po szkoleniu można było wdrażać UMLa do codziennej pracy zespołu.

Postanowiłam więc bazować na swojej prezentacji dotyczącej podejścia MDD. Jest to szkolenie zawierające w swojej treści opis faz modelowania, właśnie z użyciem języka UML. Opiera się na case study ukazującym, od opisu środowiska, przez model wymagań, architektury aż do kodu, jakie diagramy UMLowe należy kiedy stosować.
W wersji rozszerzonej skupiłam się dodatkowo na wszelakich elementach języka występujących w przestawianych diagramach - wszystko po to, by jak najdokładniej przekazać wiedzę o notacji.

Nie wiem jakie były końcowe postanowienia jeśli chodzi o zastosowanie UMLa w pracy zespołu, byłam natomiast świadkiem dyskusji poszkoleniowej i pierwsze wnioski jakie wyciągnięto nieco mnie zaskoczyły.

Okazało się, że od tej pory zespól posiada wiedzę pozwalającą na dokumentowanie tworzonego przez niego produktu. OUMLowane miało być teraz wszystko - od projektowanych funkcjonalności, poprzez istniejący kod, po instrukcje użycia produktu czy też zewnętrzne API. Co więcej, przez użycie tej konkretnej notacji praca zespołu miała się jawić jako bardziej profesjonalna, odtąd wszystko zyskać miało lepszą jakość. Zaznaczam dodatkowo, że nie chodziło o nowe podejście do produkcji dokumentacji projektowej (która do tej pory jawiła się bardziej mgliście niż statki kosmiczne w powieściach s-f), nie chodziło również o lepsze podejście do projektowania. Mówiono o rozwiązaniu wszelakich problemów komunikacyjnych i PRowych przez modelowanie wszystkiego za pomocą UMLa.

Czułam się tak, jakby nic co chciałam przekazać w szkoleniu nie zostało usłyszane, chociaż zawsze zaczynając jakąkolwiek dyskusję na temat notacji podkreślam jasno i wyraźnie kilka spraw:
- UML to jedynie język, służący temu by wszystkie osoby rozmawiające o projekcie posługiwały się tymi samymi pojęciami.
- Jakakolwiek notacja (niekoniecznie UML) jest sposobem komunikacji dotyczącym jedynie tych elementów systemu które są sporne, skomplikowane (np. często lepiej jest zastosować diagram czynności niż beletrystycznie opisywać skomplikowany algorytm) lub dotyczą wysokopoziomowej architektury systemu (w tym wypadku głownie ze względu na fakt iż takich diagramów jest niewiele, a błąd architektoniczny wiele kosztuje).
- Diagramy UML nie są wystarczające same w sobie, wymagają innych form dokumentacji i komentarzy. Jest w nich wiele miejsca na beletrystykę, nieścisłości i nie można dzięki nim pozbyć się tekstu (choćby prostego słownika pojęć).
- Diagramy służą do modelowania najczęściej w fazie projektowania. Istniejące funkcjonalności najlepiej dokumentuje kod, a jeśli tak nie jest należy zastanowić się nad refaktoryzacją, a nie nad dopieszczaniem opisu. UML niewiele tu pomoże.
- Nie należy nadużywać UMLa opisując wszystko za jego pomocą. Często lepiej nadaje się do tego język naturalny lub wiele mówiący obrazek (w szkoleniu podkreślone są obszary, które uważam za godne użycia UMLa), nie należy opisywać każdego algorytmu, każdego procesu, każdej linii kodu. W końcu UML opisuje jak działa oprogramowanie lub jakie funkcje ma spełniać, służy do komunikacji między biznesem a technologią. W instrukcjach użytkownika lepiej spisują się print screeny.
- UML nie pomoże w poprawie jakości zarówno jeśli chodzi o opis procesów biznesowych, projektu czy też kodu. Pozwoli jedynie na opisanie tego co wymyśliliśmy, lub to co w danym momencie istnieje (Co się stanie gdy zinformatyzujemy burdel? Będziemy mieć zinformatyzowany burdel.). Jeśli rozważane procesy są błędne, to właśnie takie zostaną zapisane, jeśli wymyślimy zły projekt - UML (jak papier) wszystko przyjmie. Trzeba jednak przyznać że błędy te mogą zostać zauważone dzięki diagramom prędzej niż w wielostronnicowej dokumentacji.

Tworzenie diagramów UML produkuje dokumentację, dlatego tak jak języka naturalnego należy go oszczędzać i mieć jasny pogląd na to co powinno się w niej znaleźć a co nie. Do tego potrzebna jest spójna strategia tworzenia dokumentacji, zarówno funkcjonalnej, projektowej jak i integracyjnej, czy też dokumentacji użytkownika. Cel nauki UMLa przez jego użycie w codziennej pracy nie jest sam w sobie celem złym, ale wraz z nauką notacji musi iść myśl związana z właściwym jej użyciem.

Odkąd pamiętam UML był kwestią dość śliską. Koledzy po fachu często nie chcieli go stosować, bo podobnie jak każda inna forma dokumentacji wydawał się wymagać wielkich nakładów czasowych. Kiedyś takie argumenty nie wydawały mi się poważne. Nie mogłam nie doceniać wartości "porządnego" projektu. Byłam pełna ideałów i nie docierały do mnie tak przyziemne kwestie jak terminy, zmiany i ich tempo. Potem nadeszły czasy agile'a (a teraz lean'a), i chyba najczęściej wysuwany wniosek będący parafrazą jednego z postulatów manifestu, że... nie należy pisać dokumentacji skoro jest kod :) (zaraz potem w statystykach rządzi brak projektu). Oczywiście wszyscy dzisiaj wiemy, że nie o to do końca w agile'u chodzi.

Skąd więc ostatnio ta fascynacja UMLem? Skąd wniosek, że zapewni on wyższą jakość projektu, bardziej profesjonalne podejście? No i co z tym up-frontowym projektowaniem? Czy to nie czysty waterfall? A może udawanie waterfalla przez zapisanie w diagramach czy dokumentach tego co zrobiliśmy, a czego zapomnieliśmy zapisać w pierwszej fazie? No i po co w ogóle udawać waterfalla?

Największy problem z dokumentacją to zgodność z rzeczywistością i duplikacja informacji. Właśnie stąd wynika niechęć programistów do opisywania swoich poczynań - po co 2 razy robić to samo, raz w kodzie drugi raz w na papierze? A co jeśli kod się zmieni, które działania należy uzupełniać również w tekście, jakie panują tu procedury? Dzisiejsze czasy przynoszą nam konkluzje będące kompromisem. Myślę, że wielu z nas odetchnęło z ulgą na wniosek Erica Evansa by kod był postrzegany jako dokumentacja projektowa. Ale... do tego potrzebny jest wysokiej jakości kod :) Radzę więc skupić się właśnie na tym a nie na pisaniu memoriałów, czy rysowaniu pięknych diagramów. Dokumentujmy to czego nie da się wyciągnąć z kodu to co w 2 zdaniach, obrazkach czy diagramach rozjaśni sytuację, a co wymagać będzie duuużo mniejszych nakładów niż refaktoring.

Innowacja vs. kontrola

Pewnie nikt z nas tak naprawdę nigdy nie uczestniczył w prostym projekcie. No może za czasów studiów, może gdy robiliśmy kawałek oprogramowania użytecznego dla nas samych - aplikacyjkę zarządzającą naszą domową filmoteką, organizującą nasze rachunki (choć nie posuwałabym się w tym wypadku, aż tak daleko jeśli chodzi o prostotę).

Projekty niestety mają tendencję do zwiększania swojej złożoności - nie tylko w sferze domeny biznesowej, również technologicznie, wdrożeniowo, utrzymaniowo. Projekty wieloletnie komplikują się równiez w kategoriach czysto ludzkich, poprzez nieuniknione fluktuacje osób biorących w nich udział, pojawiające się konflikty, czy zwykłe zmęczenie materiału.

Bardzo częstym błędem popełnianym w takich sytuacjach jest próba rozwiązania piętrzących się problemów przez narzucenie większej kontroli. Stworzenie procesów i zasad, których należy się trzymać. Wg panów Ogunnaike i Ray skomplikowane projekty powinny być prowadzone bazując na podejściu adaptacyjnym.

It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.

- B. A. Ogunnaike and W. H. Ray, Process Dynamics, Modeling, and Control

Powinny? A dlaczego? Ano dlatego, że podejście zwinne to tak naprawdę  większa zgodność z wymaganiami klienta - nie zwykla metodyka, zbiór zasad których należy się trzymać, bo takie zostały określone. Oczywiście zasady te istnieją, ale mają głębokie podstawy i trzymanie sie ich dąży do konkretnego celu - zgodności z uczekiwaniami klienta, lepszej organizacji projektu, czy krótszego czasu dostarczenia produktu.

No ale co takiego złego jest w samej kontroli? Właściwie to kilka rzeczy.

My ustalamy - wy słuchacie
Po pierwsze większa kontrola wprowadza atmosferę podziału na osoby mające autorytet i sposobność na wprowadzanie zmian i reszty. Przyznaję - nie jest to najgorsza sytuacja jaka się może zdarzyć. W końcu ktoś musi rządzić, a ktoś inny słuchać. Przynajmniej tak właśnie było od dawien dawna.
Osobiście nie uważam tego za dobre podejście, ale tej kwestii nie będę w tym momencie omawiać bardziej dogłębnie.

Wiem co mam robić, więc robię nie myślę
Zasady i sztywne procesy zwyczajnie oduczają ludzi myślenia. Nie mówię tu o dobrych radach, właściwych praktykach inżynierii tworzenia oprogramowania, czy wskazówkach dotyczących zastosowania odpowiednich wzorców, testów, buildów. Mówię o kontroli dotyczącej procesu, raportowania, autoryzacji, komunikacji. Często tego jak myśleć i jak pisać kod.

Kontrola jest wrogiem kreatywności
Zabawne, że często ludzie pełni pomysłów, zapału do pracy i wspierający zastosowanie nowinek technologiczno-koncepcyjnych tak chętni są do wprowadzania tej kontroli. Łatwo umyka wtedy sens adaptacyjności, samoorganizacji zespołu i jednostek oraz samej kreatywności. Osoby kontrolujące mają okazję wykazać sie twórczością w dziedzinie managementu, w zakresie kontroli, wymyślając i organizując kolejne zasady, uszczegółowiając procesy.
Reszta? Jeśli zasady zostaną wprowadzone może jedynie się ich słuchać. Na własną inwencję pozostaje niewiele miejsca.
A jednak cała siła kreatywności leży w tym, by jasno i wyraźnie wyznaczyć wizję, cel jaki należy osiągnąć. To w jaki sposób zostanie on osiągnięty, jest polem do manewru dla pomysłów. Jeśli zaczniemy ludziom mówić JAK coś zrobić - otrzymamy ... po prostu grupę osob robiących to co ustaliliśmy. Jedyną szansą na rozwój dla nich pozostanie bunt. Czy to nie oczywista sprzeczność? :)

DbC - czyli wyraź swoje intencje

Dzisiaj nieco koncepcyjnie (no tak - a kiedy nie było :)) na temat idei kontraktów, tego jak podchodzić z tą myślą do projektowania i implementacji. O czym konkretnie myśleć i w ogóle PO CO w ten sposób myśleć.

Sama idea Design by Contract wprowadzona została przez twórców języka Eiffel. Nie wiem co panowie mieli na myśli jeśli chodzi o ideologię, lecz zwykle przedstawiana jest przez wprowadzenie pojęć:

• wymagania (precondition) - warunki wejściowe kontraktu,
• zapewnienia (postcondition) - warunki wyjściowe kontraktu,
• niezmienniki (invariant) - warunki obowiązujące dla kontraktu.
  

Dodatkowo omawiane są wszelakie techniki obsługi błędów (gdyż każdy warunek tak naprawdę stanowi asercję), zasady pisania warunków, łapania wyjątków, włączania przeróżnych opcji konkretnych narzędzi wpierających kontrakty.

Ja wolałabym się skupić na tym czym tak naprawdę jest kontrakt. Oczywiście nie po to by prowadzić akademicką dyskusję, lecz by tworzyć KOD...
Dla mnie cała idea polega na zdefiniowaniu intencji klasy - za pomocą formalnej notacji (wręcz kodu) jesteśmy w stanie opisać to czego użytkownik może się spodziewać po klasie i jej metodach oraz to czego metody oczekują metody gdy się je wywołuje.

Przypomina to ... kontrakt. Ale taki zwykły - międzyludzki.
Jeśli dostawca oferuje pewną usługę, związana jest ona z konkretnymi zasadami dotyczącymi sposobu korzystania z niej. Klient podpisując odpowiednią umowę (kontrakt) musi spełnić te wymagania (np. za nią zapłacić). W odpowiedzi dostaje 'gwarancję', a przynajmniej zapewnienie opisowe dotyczące zakresu tej usługi. Powiązanie to jest obustronne - jeśli klient nie zapłaci za usługę - jej efekty mogą być nieprzewidywalne. Z kolei jeśli usługa nie jest zgodna z zapewnieniami - nie spełnia założeń kontraktu, dostawca może się spodziewać że za nią nie zapłacimy...

No tak... ale jak to się ma do programowania. Fajna idea, ale do czego się może nam przydać? Tak naprawdę jeśli chodzi o kod kontrakty wprowadzają dwie wartości:
- sposób obsługi błędów,
- formalną dokumentację zachowania klasy lub metody.

Ale jak to? Ano tak to...
Dla przykładu rozważmy dostawcę usług internetowych. Wymagania kontraktu dotyczą płacenia rachunków w terminie. Jeśli klient tego nie robi - dostawca nie musi np. spełniać warunków dotyczących szybkości łącza (albo może je po prostu odciąć, ale nie można być pewnym ani dnia ani godziny kiedy się to stanie :)). Sęk w tym, że klient nie może w takim wypadku spodziewać się jakości usług zapisanej w umowie. Z kolei jeśli wymagania zostaną spełnione, to klient spodziewa się spełnienia zapewnień kontraktu - może np. zaplanować (powołując się na szybkość łącza) ściąganie potrzebnych danych.

Wszystko fajnie, tylko jak to się ma do kodu? Może wyjaśnię na przykładzie.
    public void Add2Account(int amount)
    {
        account += amount;
    }
Oto metoda, której zadaniem jest zwiększenie kwoty na rachunku klienta banku. Nawet przy tak prostej metodzie powstaje dużo pytań: Czy metoda przyjmuje wartości ujemne (wtedy metoda tak naprawdę zmniejszałaby kwotę)? Co jest wynikiem metody?

Odpowiada na nie odpowiedni kontrakt. Dotyczyć on będzie: wymagań (warunków jakie muszą spełniać parametry) i zapewnień - metoda zawsze zachowa się w określony sposób:
    require:
    amount > 0
    public void Add2Account(int amount)
    {
        account += amount;
    }
    ensure:
    account = old(account) + amount

Od razu piszę, że nie jest to żadna formalna notacja - jedynie pseudo-kod - pomysł na w miarę przejrzyste zapisanie warunków kontraktu.
Skoro kontrakt metody mówi, że przyjmuje ona jedynie wartości dodatnie, to nie musimy tego sprawdzać w kodzie samej metody. Zapewnienia natomiast przydają się klientom klasy. Teraz oni nie muszą w swoim kodzie robić tysiąca sprawdzeń. Wiedzą, że kwota na rachunku po wykonaniu operacji będzie zawsze większa niż kwota wcześniejsza.
Trzeci rodzaj asercji (niezmienniki) dotyczy zachowania całej klasy - jest to zbiór warunków spełnianych zawsze po wykonaniu jakiejkolwiek metody.

Tak więc podsumowując, benefity z myślenia 'kontraktowego' są następujące:
1. Jasno widać jak dzięki takiemu podejściu pozbywamy się tysiąca if'ów w kodzie.
2. Dokumentacja metody (i klasy) wyrażona jest w kodzie - dotyczy zarówno tego, czego się można spodziewać po zachowaniu (zapewnienia), ale również jak jej używać by działała w prawidłowy sposób (wymagania). Dla naszego przykładu możemy się np. spodziewać istnienia metody, która zmniejsza kwotę na rachunku klienta banku.
OK - to było koncepcyjne i meta-notacyjne. Konkrety następnym razem.

Antyscrum - 10 najczęstszych błędów

Pewnie napisano już miliony stron na temat samego scruma, tego jakie wprowadza benefity, jak ułatwia pracę, jak wykorzystać tę metodykę, by dostarczać lepsze i tańsze oprogramowanie. Bez obaw - nie mam zamiaru ani tego powtarzać ani podsumowywać.
Chcę napisać o czymś zgoła przeciwnym - i nie chodzi mi o stwierdzanie, iż metodyka nie spełnia tego co wcześniej podkreśliłam. Skupię się raczej na pojęciu ostatnio wprowadzonym w moim otoczeniu - na tzw. antyscrumie. W skrócie oznacza ono wszelakie błędy jakie popełniane są w procesie tworzenia oprogramowania pod płaszczykiem stosowania scruma.

Oto 10 najczęstszych sytuacji, które dyskwalifikują w moim pojęciu użycie terminu scrum:

1. Przeprowadzanie daily scrum'ów - oczywiście nie mówię o samym fakcie ich przeprowadzania, tylko sposobie. W założeniach powinno się odpowiadać na 3 pytania (Co udało mi się zrobić wczoraj?, Co będę robić dziś? Z czym miałem problem?), a samo spotkanie powinno trwać 15 min. Problem zaczyna się w momencie gdy spotkanie przestaje spełniać swoją funkcję - ludzie nie odpowiadają na wszystkie pytania, nie wszyscy odpowiadają (lub nie wszystkich prosi się o wypowiedź?), a w końcu zajmują się omawianiem szczegółów implementacji i spotkanie zamienia sę w dialog dwóch osób.
   
2. Brak scrum review, czyli najwięszy problem w każdej metodyce, lub tez w każdym procesie.
   
3. Sprint planning meeting - spotkanie mające trwać 8 godzin i w którym udział ma brać cały zespół. Z mojego doświadczenia wynika, iż takie spotkania się nie odbywają - w każdym bądź razie nie trwają 8 godzin tylko podzielone są na 2-3 spotkania ok. godzinne. No i oczywiście nie uczestniczy w nich cały zespół, tylko pewnie postacie go reprezentujące (często kierownik zespołu). Pewnie wg niektórych na takich spotkaniach wystarczy wiedza tych, którzy są tzw. graczami kluczowymi... Tylko, że trochę mi to nie pasuje jeśli chodzi o zasady scruma.
   
4. Outputem spotkań sprintowych powinny być backlogi - zbiór zadań do wykonania przez zespół realizujący, z którego 'czerpie' w trakcie trwania sprintu. Często jednak nie ma za bardzo z czego czerpać - każda osoba ma dosłownie kilka zadań, które musi zrobić w określonej kolejności i na dodatek związane jest to z zadaniami innych osób. Najczęściej nie ma sytuacji gdy można wybrać sobie coś z backloga, czy też, by dane zadanie mogła wykonać więcej niż jedna osoba.
   
5. W scrumie istnieją 3 role: zespól, scrum master, product owner. No ale ponieważ w firmach pokutują przeróżne przekonania zaszłościowe - trzeba każdemu znaleźć miejsce, nawet jeśli tego miejsca nie ma. Tak więc PM staje się scrum masterem, kierownicy stają się PMami, lub kluczowymi graczami zespołów. Pół biedy jeśli są scrum masterami, ale wtedy często faworyzują swoich ludzi i wrzucają w trakcie spotkań zagadnienia związane z ich pracą nie koniecznie dotyczącą omawianego projektu.
6. Zbyt duże zespoły - optymalna liczba osób scruma nie powinna przekraczać 7 osób. Jest to najczęściej łąmana reguła. Identyfikuje to problem jako zbyt skomplikowany, a panować nad nim ma jeden scrum master.
   
7. Faworyzacja tzw. osób kluczowych - najczęściej wyrażana tym, że najważniejszymi problemami są problemy tych właśnie osób, to one zapraszane są na wszystkie spotkania, one decydują o większości spraw i przytłaczają resztę zespołu. Często jest to wynik zbyt dużego zespołu - jeśli ciężko ogarnąć zbyt duży zespół, najłatwiej skupić się na osobach najbardziej widocznych. Wtedy też najłatwiej osoby kluczowe wykreować.
   
8. Brak agentowości - problem związany z dwoma poprzednimi. Agnetowość to moim zdaniem najważniejsza cecha scruma. Po to go wymyślono - by problem podzielić na mniejsze, by rozdzielić go na agentowe zespoły umiejące sobie same poradzić, by uniemożliwić centralne sterowanie, bo przy złożónych problemach się ono nie sprawdza. Ale stare nawyki cięzko zmienić... a najciężej nawyk posiadania kontroli.
   
9. Gdzie jest jakość? To zarzut do wszystkich, którzy metodyki zwinne rozumieją na swój sposób. Skoro mamy stworzyć oprogramowanie, to po co się martwić testami, dokumentacją czy przygotowywaniem szkoleń? Jesteśmy zespołem realizującym - piszmy więc kod. Projektowanie czy wymyślenie architektury spowoduje, że system powstanie później. Lepiej zacząć pisać i zbaczyć co z tego wyniknie, klient i tak zmieni zdanie 10 razy, więc po co się zastanawiać - lepiej brać się do roboty. Gorzej jeśli decyzje o elastyczności pokutują później niesamowitą ilością błędów, niemożnością rozszerzalności czy niekończącym się czasem na konserwację.
   
10. Czy to agile czy jednak waterfall? A może inna metodyka. Skoro nie mamy sposobu na wprowadzenie elastyczności, czy ogólnie pojmowanego ogarniania zmian, to może po prostu nie jesteśmy w środku zwinnej metodyki? A może jej nie potrzebujemy?
    

Ktoś zaraz mi powie - 'Ale skoro jest tak źle, skoro nie są spełnione podstawowe założenia scruma, to jak w ogóle ktokolwiek może taki proces określać tym terminem?'. Otóż to - proces ten nazywam ostatnio mianem antyscrum :) Kierownicy, dyrektorzy, PMowie, a nawet zespoły realizujące twierdzą, że stosują scruma, a nawet chwalą się tym nie zdając sobie sprawy z podstawowych błędów jakie popełniają.
Najczęstszym wytłumaczeniem jest właśnie agile - 'Nie musimy się sztywno trzymać regułek. w końcu to agile. Bierzemy ze scruma to, co nam pasuje.'. Niby prawda, tylko jeśli jedyne co pasuje, to fakt ustanowienia codziennych spotkań i pseudo Backlog, to może wymyślmy dla tej metodyki oddzielną nazwę.
Inne usprawiedliwienie: 'O co chodzi? Nasza metodyka działa. Skoro działa, to jest ok.'. Problem w tym, że gdy zorientujemy się, że metodyka nie działa, to na pewno będzie już za późno. Scrum jest metodyką, która ma rozwiązywać problemy i na bieżąco je identyfikować. Antyscrum na to nie pozwala - oddalenie się od ludzi realizujących projekt, brak podsumowań, niedbałe codzienne spotkania, to najprostsza droga do lawiny nieszczęść.
Apeluję o zwracanie uwagi na szczegóły - nawet jeśli dotyczą agile'a. Agile nie oznacza ani braku dokumentacji, ani nie stosowania się do reguł i procesów, ani ogólne pojmowanej anarchii. Jest sposobem na to by wprowadzić do procesu elastyczność, tak by zoptymalizować to co chcemy zoptymalizować - jakość, budżet czy termin.

TechEd 1.0

Dzisiaj co nieco o organizacji samej konferencji...

Trwała od poniedziałku do piątku 11-15 maja w godzinach od ok. 8 do 17. Obejmowało to 5 sesji dziennie - 2 przed lunch'em i 3 po. Miejsce? - Los Angeles Convention Center.
Po pierwsze - rejestracja. Generalnie stanie w kolejkach, ale przyznać trzeba - szło całkiem gładko. Po tym etapie giveaways'y jakie miałam na stanie:

• torba - sztuk 1 :),
• nametag,
• koszulka - w rozmiarze M, bo na S-ki nie byli przygotowani lub mamy na świecie dużo małych informatyków i zabrali wszystkie przed tym jak się pojawiłam,
• duży i mały format przewodnika konferencyjnego,
• mnóstwo literatury, z ktorej chyba tylko msdn magazine byl interesujacy,
• mnóstwo reklam,
• kupon zapewniający rabat na egzaminy M$.

Muszę przyznać, że byłam pod wrażeniem profesjonalizmu obsługi imprezy - zwłaszcza osób kierujących uczestników do odpowiednich sal, w miejsca spożywania posiłków, uzupełniających zapasy przekąsek, napojów i kawy. Ach.... kawa... no tak... firmowana marką Starbucks - w rzeczywistosci zwykla konferencyjna. Dla porównania w jednym ze skrzydeł centrum była firmowa kawiarnia - kto się skusił ten poznał prawdę. No cóż - bywa i tak. Nie można oczywiście było narzekać na zawartość lodówek i co jeszcze ważne dla takiego łasucha jak ja - na zapas przekąsek. Były też owoce - wspominam o tym, bo może ktoś lubi się zdrowo odżywiać, a ja nie chcę konferencji przedstawić jako miejsca gastrologicznej rozpusty. Chociaż... jedzenie było pycha :).
Z panów nawoływaczy szczególnie zapadał w pamięć ten który namawiał do odwiedzin sklepu konferencyjnego. Nie wiem na ile był skuteczny, ale na pewno zauważalny, a raczej dobrze slyszalny - nawet z innych pięter. BTW - 20% upustu na ksiazki - NICE!

Konferencji towarzyszyly przeróżne wydarzenia jak Party with Palermo, Partner Expo czy Jam on IT. Imprezy odbywały się w dość standardowym scenariuszu. Ekspozycje oferowały mnóstwo konkursów, rozdawały koszulki, długopisy i inne gadżety. Pierwsza oznaka kryzysu - już nie tak łatwo zdobyć myszkę czy pendrive'a. Jam on IT odbyło się niestety bez mojego udziału - dzisiaj mogę z czystym sumieniem powiedzieć, że nie była to świńska grypa. Załuję, bo podobno widok prelegentow w zespole zabawiającym gości był bezcenny :D

Inne ciekawostki?

• Pomysł rozkładających się reklamówek, do których można wrzucić niepotrzebne papiery - wykorzystany przeze mnie niemal na starcie.
  
• Fantastyczne śniadania - to pewnie efekt amerykańskiej tradycji - nie zwykłe drożdżówki, ale czego tylko dusza zapragnie - od jaj w rożnej postaci, pieczywa, ciastek, platków, jogurtów, po smażone kiełbaski czy bekon. Mniam - dobra, kończę, bo mam ślinotok na wspomnienie ...
  
• Another nice thing - shuttle między hotelami a centrum konferenyjnym. Podobno fakt, iż nie kursowaly cały dzień jest oznaką kryzysu. Ja byłam zadowolona nawet obecną sytuacją.

O wartości merytorycznej napiszę kiedy indziej, bo konferencja już daleko za nami i czas zająć się bardziej aktualnymi tematami.

TechEd - relacja 0.1

Zacznę może nietypowo (ale tylko może :) ) - od relacji pogodowo-rekreacyjnej z pobytu w LA. Dodam jedynie na początek, gwoli wyjaśnienia, ze wyjazd dotyczył udziału w konferencji TechEd.

Nie dołączam na razie żadnych zdjęć, bo znajduja sie na karcie Piotrka - jak jakieś dostanę z checia zamieszcze :) Aha - moimi towarzyszami byli Szymon i Piotrek, ale to pewnie wiecie z ich blogów :)
Z wieści pogodowych, to prawdę mowiąc spodziewałam sie czegoś innego - palącego slońca, plaży, palm, roznegliżowanych modelek (i modeli oczywiście), a przede wszystkim aktorów czajacych sie na kazdym rogu i pragnących mnie poznać (od biedy mógłby to być Brad Pitt...). Zamiast tego - chmury, śmieci, luksusowe budynki zaraz obok etnicznych dzielnic i stojących na rogach budek z hot-dogami. Do plaży jedzie się godzinę, a palmy co prawda były, ale nie robiły takiego wrażenia jak mogłoby sie wydawać.
Wiem, wiem - trzeba było się zakwaterować w Beverly Hills, albo Hollywood - wtedy poczułabym prawdziwą Californię. No ale niestety - wybór miejsca byl zdeterminowany nie do końca moimi decyzjami. Zakwaterowani byliśmy w hotelu w Downtown znajdującym się na pograniczu dzielnic latynoskiej i Little Tokyo.

Repertuar zwiedzonych miejsc byl dość ograniczony, z uwagi na fakt iż sesje kończyły sie o 18, a dodatkowo czasami imprezy sponsorów przeciagały pobyt w centrum koferencyjnym do godzin późniejszych. Na domiar złego zachorowałam - wlasciwie wszyscy zachorowaliśmy (tak, tak - swińska grypa, wiem :P ), ale mnie kopnęło dość porządnie i wiekszość wieczorów spedzałam w łóżku. Na zwiedzanie przeznaczyliśmy więc weekendy 9-10 oraz 16-17 maja.

Czas spędzony beletrystycznie przedstawiał się następująco:
1. Plaża w Santa Monica - w życiu nie sądziłam, że można zmarznąć i spalić się jednocześnie.
2. Aleja gwiazd w Hollywood - nuuudy...
3. Universal Studios Hollywood - świetny park rozrywki. Dawno się tak nie wybawiłam - polecam.
4. Venice Beach - niemal burza i zakaz kąpieli, ale przynajmniej byli serferzy:)
Najciekawszym dniem okazal sie dzien spedzony na rollercoasterach. Co jak co, ale rozrywkę Amerykanie serwują pierwszorzędnie. Wieczorem wybraliśmy się na pyszne steki. Tak... :) to był z pewnością dobry dzień.

Z wszystkiego w Stanach najbardziej podobał mi się profesjonalizm ludzi pracujących w uslugach (nie WCF-owych tylko analogowych :P) - nikt tam nie ma do mnie (w sensie do klienta) pretensji o to, że pracuje tam gdzie pracuje i że robi to co robi. Obowiazkiem tego kogos jest sprawić mi przyjemność. I to mi sie podoba :D

No cóż.... - to tak w telegraficznym skrócie. Moze następna relacja bedzie dotyczyć bardziej merytorycznej strony wyjazdu :)