Michał Giergielewicz

dla ^khaal‘a: joemonster.org(s)

specjalnie dla projektantów: joemonster.org(s)

EGG! ;>

Dziś ostatnia część opisu MongoDB

MongoDB jest w stanie w całości przejąć obowiązki MySQL, jednak najlepszą drogą dla już istniejących portali jest ewolucyjne podejście i implementacja Mongo tam gdzie można najlepiej wykorzystać jego możliwości.

Pierwszym z takich miejsc jest tak zwana druga warstwa cache’owania (secondCache). Najczęściej stosowanym systemem cache’owania w portalach internetowych jest Memcache – jest to system który nie wspiera mechanizmów replikacji i failovera, więc w wypadku uszkodzenia maszyny, nie ma możliwości zapewnienia ciągłości dostępu do cache’a. W takim środowisku stawiamy MongoDB jako drugą warstwę. Systemy odpowiedzialne za odczyt danych z bazy i ich zapis do cache’a modyfikuje się o dodatkową funkcję która podczas zapisu danych zapisuje je dodatkowo do Mongo a przy odczycie w razie braku odpowiedzi z Memcache, próbuje uzyskać dane z Mongo. Samo MongoDB w takim systemie pracuje w systemie failoverowym (tzw. Replikacja Master- Master, jedna maszyna jest online, druga pracująca jako slave jest w trybie oczekiwania, w razie awarii pierwszej maszyny, druga przejmuje jej obowiązki i staje się masterem, a pierwsza po usunięciu usterki samoczynnie przełącza się w tryb slave’a i przyjmuje zreplikowane dane), co zapewnia bardzo duży stopień bezpieczeństwa i uodparnia system cache’owania na awarię jednego z podsystemów.

Drugim etapem integracji MongoDB z portalem jest tak zwany LazyCache czyli izolacja warstwy prezentacji od warstwy danych. W tym systemie dochodzi kolejna maszyna Mongo pełniąca rolę kolejki. Systemy dostępu do danych zostają zmodyfikowane w taki sposób, że każde zapytanie odczytujące dane z bazy jest zapisywane w kolejce wraz z informacją o czasie cache’owania tych danych. Samego odczytu z bazy dokonuje mechanizm kolejki, wykonując zapamiętane zapytania w zadanym odstępie czasu. Pobrane dane są w wstępnie przetworzonej formie zapisywane do Mongo pełniącego funkcję secondCache’u. Dopiero stąd dane zapisywane się do Memcache’a (mechanizm mongo pozwala na zapamiętywanie całych list obiektów jak i pojedynczych obiektów co umożliwia aktualizację w Memcache’u danych w sposób w jaki do tej pory nie można tego było wykonać np. w razie aktualizacji obiektu o id 15 mongo może zaktualizować ten obiekt w Memcache’u jak również wszystkie listy które zawierają kopie tego obiektu – sam Memcache tego nie potrafi). Sam Memcache nigdy nie wygasza danych które zapamiętał, tak więc nawet w wypadku uszkodzenia mechanizmu kolejki, serwis zawsze będzie miał dostęp do danych. Nie będą może one tak aktualne jak by mogły być, jednak sam fakt, że zawieszenie się bazy danych, lub mechanizmu kolejki nie będzie powodowało awarii serwisu jest ogromnym krokiem naprzód. Dodatkową zaletą jest fakt, że można zarządzać obciążeniem bazy danych modyfikując prędkością kolejki i np. przyspieszać bądź spowalniać proces aktualizowania się danych w serwisie, i to nie tylko na poziomie całego portalu ale, przy zastosowaniu odpowiednio zaprojektowanych paneli z dostępem do danych kolejki, na poziomie pojedynczego zapytania.

W przyszłości opublikuję kilka bardziej praktycznych informacji dotyczących mongo, pokażę praktyczne implementacje w PHP i może jakiś działający przykład serwisu wykorzystującego mongo jako podstawową bazę danych

Do zobaczenia :)

Dziś część druga opowiastki o MongoDB

Kolekcje można przeszukiwać pod kątem istnienia dokumentów spełniających określone kryteria (np. Pole „płeć” ma wartość „k” lub imie zaczyna się na „Mich”), w tej chwili nie ma jeszcze możliwości prawdziwego przeszukiwania pełnotekstowego ale istnieją znane obejścia tego problemu a developerzy Mongo pracują nad natywną obsługą tej funkcji. Otrzymane wyniki można dowolnie sortować, ograniczać i agregować. Mongo pozwala oczywiście na zakładanie indeksów. Dodatkowo Mongo zapewnia atomowość operacji na poziomie dokumentu i nie wymaga blokady kolekcji podczas dodawania danych bądź ich aktualizacji. Tylko usuwanie danych i zakładanie indeksów wymaga założenia blokady dla wątków odczytujących.

Mongo oferuje też bardzo rozbudowane funkcje replikacji, sharding i posiada wbudowane mechanizmy failover’a, potrafi też pracować w środowiskach rozproszonych. Jest więc odporne na awarie pojedynczego węzła systemu.

Podstawową różnicą między MongoDB a systemami relacyjnymi jest brak możliwości wykonywania złączeń między kolekcjami – mówiąc prosto MongoDB nie ma JOIN’ów, nie ma relacji. Ważnym ograniczeniem jest też brak transakcyjności dlatego też Mongo nie jest polecane dla systemów finansowo-księgowych, płatniczych czy bankowych.

Należy zaznaczyć że MongoDB nie wypracowało jakiegoś odkrywczego podejścia do wyszukiwania czy wstawiania danych. Większość stosowanych mechanizmów jest znana i wykorzystywana od dawna również w bazach relacyjnych (np. indeksy oparte są na zwykłych drzewach B-Tree). To czemu MongoDB zawdzięcza swoją szybkość to głównie składowa dwóch rzeczy. Po pierwsze wszystkie dane trzymane są w pamięci operacyjnej i dopiero stamtąd zapisywane na dysk, po drugie język zapytań rozbudowany został o komendy umożliwiające operacje atomowe (jednoczesne zapytania modyfikujące i pobierające dane są dopuszczalne i nie blokują kolekcji). Nawet te dwie niewielkie modyfikacje powodują znaczący przyrost wydajności. Dodajmy do tego funkcjonalność kolekcji „wbudowanej” (embed), która po części zastępuje referencje używane w bazach relacyjnych, wykorzystanie zalet formalnej specyfikacji DBRef umożliwiającej „łączenie” obiektów z różnych kolekcji między sobą (co przyspiesza wyszukiwanie i łączenie wyników z różnych kolekcji) czy wbudowanie w MongoDB możliwości tworzenia struktur drzewa (nested tree, parent-child).

To tylko przykładowe możliwości MongoDB a każde z nich daje przyrost prędkości. I właśnie to jest siłą tego systemu – wykorzystuje on znane technologie, tak aby uzyskać wysoką wydajność dla bardzo konkretnych zastosowań. MongoDB nie sprawdzi się jako hurtownia danych – nie jest do tego stworzony i większość jego zalet nie będzie miała w takim przypadku zastosowania. Jeśli jednak użyjemy tego systemu do zastosowań real-time (takich jak portale internetowe), wychodzi na jaw jego siła.

Przedstawiam pierwszą część moich przemyśleń dotyczących MongoDB. Zajmuję się tym już od jakiegoś czasu, i zauważyłem parę ciekawych prawidłowości którymi chciałbym się podzielić. Na początek trochę informacji podstawowych…

Wymagania wobec baz danych w portalach internetowych w podejściu tradycyjnym. MySQL jest najpopularniejszym obecnie systemem baz danych wykorzystywanym w środowiskach portali internetowych. Jest to relacyjna baza danych spełniająca wymogi wydajnościowe i pojemnościowe nawet dla dużych serwisów. W czasach tzw. WEB1.0 czyli wtedy, gdy użytkownicy witryn internetowych byli biernymi „oglądaczami” prezentowanych treści, a jedyną formą interakcji była funkcjonalność forum internetowego, baza MySQL była więcej niż wystarczającym narzędziem. Jeśli założymy, że nawet duży portal internetowy o charakterze kontentowym (wp.pl, onet.pl itp) posiada nie więcej niż kilkuset redaktorów tworzących treść serwisu, to przekłada się to na nie więcej niż kilka-kilkanaście tysięcy zapisów do bazy MySQL na dobę. Przy tym założeniu baza MySQL jest idealnym narzędziem ponieważ jej siła najbardziej uwidacznia się przy dużej dysproporcji między poziomem zapisu a odczytu (dokładnie mało zapisów, dużo odczytów). Nawet bardzo duża pula odczytów w takim serwisie może zostać skutecznie rozłożona na slave’y w replikacji MySQL. Jeśli uruchomimy replikację na jednej maszynie typu master, to bez najmniejszego problemu obsłuży ona cały ruch zapisujący dane od redaktorów i prześle go na dowolną praktycznie ilość slave’ów, a duża pula odczytów rozłoży się poprzez loadbalancing na kilka slave’ów. W takim systemie jest możliwe obsłużenie naprawdę bardzo dużego ruchu przy rozsądnych nakładach sprzętowych.

Tak zwane WEB2.0 całkowicie odmieniło rzeczywistość ‘sprzętową’ w portalach internetowych. Wokół witryn zaczęły tworzyć się społeczności przyciągane możliwościami aktywnego tworzenia treści serwisu, wymiany myśli, poglądów, współpracy i integracji ludzi. W Web2.0 przeważa tzw. User Generated Content, co przekłada się oczywiście na kwestie przechowywania i serwowania informacji z poziomu baz danych. W serwisach społecznościowych nie ma kilkuset redaktorów tylko kilka tysięcy lub nawet kilka milionów! Facebook czy NK to sztandarowe przykłady bardzo dużych portali społecznościowych i na ich podstawie można przeanalizować jakim wymaganiom musi sprostać baza danych.

Ogromny wzrost zapisów i modyfikacji w bazie danych spowodowany jest tym, że każdy dotychczasowy bierny odbiorca treści, stał się aktywnym twórcą. Taki wzrost zapisów jest czymś do czego MySQL po prostu nie został stworzony. Zapis do bazy, zwłaszcza modyfikacja rekordu powoduje zablokowanie całej tabeli, co powoduje opóźnienia w odczytach i rosnące kolejki ‘selectów’ czekających na odblokowanie tabeli. Jeśli zapisów jest dużo, blokady powodują ogromny wzrost obciążenia i w rezultacie zawieszenie procesu MySQLd. MySQL są techniki i narzędzia które mogą w pewnym stopniu ograniczyć ten problem, lecz w praktyce bardzo szybko dochodzi do wysycenia systemu i jedynym rozwiązaniem jest ucieczka w sprzęt czyli rozbudowa farmy serwerów MySQL. Takie rozwiązanie jest bardzo kosztowne i w praktyce nieopłacalne. Na szczęście istnieje inne rozwiązanie.

MongoDB to nierelacyjna baza danych pracująca w modelu ‘Document Oriented’. Idea stojąca za Mongo jest następująca: Systemy relacyjne takie jak MySQL, Oracle czy Mssql są bardzo rozbudowane, mają ogromne możliwości lecz często okupione jest to niższą wydajnością i skomplikowaną obsługą. Z drugiej strony systemy typu ‘key-value’ takie jak Mamcache, Redis, czy Voldemort są wyjątkowo proste w budowie i oferują stosunkowo niewiele funkcji (w uogólnieniu to tablice hashowe, czasem rozbudowane o proste mechanizmy wyszukiwania czy agregacji i bardziej rozbudowane funkcje wydajnościowe takie jak klastrowanie, możliwość pracy w systemach rozproszonych z wysoką odpornością na awarie) lecz ich zaletą jest ogromna wręcz prędkość działania i niezawodność. MongoDB spina te dwa podejścia starając się przejąć to co najlepsze z systemów relacyjnych czyli funkcje wyszukiwania, sortowania, agregacji a z systemów key-value szybkość działania i dużą odporność na awarie.

W efekcie MongoDB zapewnia doskonałe lekarstwo na problemy które przyniosło Web2.0. Posiada możliwość definiowania kolekcji (tabel) i dokumentów (krotek), lecz ponieważ jest bazą typu schemeless nie ma potrzeby definiowania struktury tych obiektów, więc każdy z nich może zawierać inne pola np. jeśli weźmiemy pod uwagę kolekcję użytkowników, to jeden dokument może zawierać pola ‘imie’, ‘nazwisko’, ‘email’ a drugi ‘imie’, ‘login’, ‘status’ – oba dokumenty mogą leżeć we wspólnej kolekcji. W każdym przypadku pola niezdefiniowane są niejawnie definiowane jako puste. Jedynym wymogiem jest istnienie unikalnego klucza głównego dla każdego dokumentu wewnątrz jednej kolekcji o co zresztą dba samo Mongo. Takie podejście jest intuicyjne i proste w implementacji a dodatkowo oszczędza miejsce (nie ma potrzeby rezerwacji miejsca na pola które mają puste wartości, i łatwo wprowadzać zmiany do danych przechowywanych w kolekcji – nie ma potrzeby redefiniowania struktury jak w wypadku baz relacyjnych)

Sprint

Każde zadanie (historyjka) z listy otrzymuje DoD (Definition of Done), które formułuje Product Owner. DoD określa sposób potwierdzenia, że dana historyjka została poprawnie wykonana (np. zadanie przetestowane, działające, w docelowej szacie graficznej, po testach na użytkownikach docelowych, uruchomione na serwerze testowym itp). Wybrana przez Product Owner’a lista zadań trafia na Sprint Backlog i do realizacji przez Team. Na tablicy w widocznym miejscu zapisywany jest ogólny cel przebiegu (np. Uruchomienie funkcjonalności forum). Wszystkie historyjki ze Sprint Backlog’u są umieszczane na tablicy w formie karteczek, tak by przenosząc je w konkretne miejsca tablicy, można było wizualizować postęp prac. Podczas przebiegu Product Owner, ani żadna inna osoba nie może wpływać na przebieg pracy Team’u. Team realizuje kolejne historyjki samodzielnie wybierając kolejność, przypisując osoby odpowiedzialne zgodnie z zasadą samoorganizacji, na bieżąco konsultując problemy i niejasności z Product Owner’em. Sposób realizacji, użyta technologia, wybrane algorytmy czy narzędzia leżą tylko w gestii zespołu.

Podczas przebiegu odbywają się Daily Scrum Meeting – mają one postać kilkunastominutowego spotkania przy tablicy. Spotkanie prowadzi Scrum Master. Celem spotkania jest ustalenie aktualnych postępów w pracy. Jest to potrzebne do wyrysowania Burndown Chart’u, czyli wykresu spalania opisującego jak wiele pracy jeszcze pozostało. Pozwala to ocenić czy zespół pracuje wydajnie i czy wyrobi się z pracą na koniec przebiegu. Spotkanie pozwala również na bieżąco monitorować czy nie pojawiają się jakieś przeszkody natury technicznej bądź organizacyjnej (rozwiązywanie takich problemów jest w gestii Scrum Mastera – jego zadaniem jest zapewnić komfortowe warunki pracy Team’owi). W spotkaniu może uczestniczyć Product Owner, który ma wtedy aktualny pogląd na stan prac, może też sugerować błędne ścieżki i wskazywać miejsca gdzie team dokonał błędnej interpretacji zadania. Jeśli wykres spalania wskazuje na możliwe niedotrzymanie założonych celów w wyznaczonym terminie, cały zespół może zdecydować o wyrzuceniu z przebiegu jakiegoś zadania bądź zmianie DoD – takie decyzje muszą być jednak zatwierdzone przez Product Ownera. Wyrzucone zadanie trafia na następny przebieg. Jeśli okaże się że Team wyprzedza plan, jest możliwość dołożenia zadania z Product Backlog’u – to również zatwierdza Product Owner.

Demo, retrospekcja

Przebieg kończy się zgodnie z przyjętym na początku terminem. Na koniec przebiegu wszystkie zadania powinny spełniać DoD a główny cel powinien zostać osiągnięty. Potwierdzeniem przebiegu jest Demo na którym zespół prezentuje Product Owner’owi (i Klientowi) działającą funkcjonalność, opisuje ew. braki i zapisuje uwagi czy usterki zgłoszone przez Product Owner’a. Lista poprawek jest następnie wyceniana i dołączana do następnego przebiegu (to oczywiście leży w gestii Product Owner’a – on decyduje czy błędy poprawiać teraz czy później, albo czy je zignorować).

Po demie odbywa się jeszcze wewnętrzne spotkanie zespołu czyli retrospekcja, na którym przedstawiane są błędy poczynione w ostatnim przebiegu, problemy które wynikły itp. Podczas retrospekcji zespół stara się ustalić możliwe usprawnienia, notuje obszary krytyczne i sposoby ominięcia podobnych błędów w przyszłości. Retrospekcja kończy przebieg i pojedynczy cykl procesu Scrum. Product Owner dostarcza zespołowi nowy Sprint Backlog i rozpoczyna się następny przebieg.

Powtarzalność etapów Scrum’a, daje możliwość wyłapywania błędów procesowych i ich korektę. Adaptacja do zmieniającego się środowiska jest dużą korzyścią dla procesu wytwórczego. Ciągła komunikacja między członkami Team’u, Product Owner’a i przy współpracy Scrum Master’a, powoduje, że zespół angażuje się w projekt, nie tylko od strony technicznej ale także biznesowej. Praktyka pokazuje że Product Owner, widząc sposób pracy zespołu i mając częsty wgląd w jego postępy, jest w stanie elastycznie reagować na zmiany, dostosowując projekt niejako „na bieżąco” do swoich potrzeb. Z kolei zespół mając ciągły kontakt z Product Owner’em jest w stanie szybko i na miejscu wyjaśniać wszelkie problemy lub błędne interpretacje jakichś funkcji produktu. Scrum Master zapewnia wszystkim członkom teamu wsparcie z zakresu metodyki czy dobrych praktyk zarządzania zmianą. Całość daje bardzo widoczne efekty synergii. Metodyka Scrum pozwala szybko zobaczyć efekty prac – poprzez swego rodzaju wymuszenie komunikacji między biznesem (Product Owner) i IT (Team) daje obu stronom możliwość aktywnego i prostego sterowania procesem wytwórczym. W rezultacie zwiększone są szanse zachowania zasady trójkąta czyli dostarczenie produktu wysokiej jakości, w wyznaczonym czasie i przy zakładanych zasobach.

Podsumowanie

Jak każda metodyka Scrum posiada także wady. Podstawowe założenia określają maksymalną wielkość zespołu na 8-10 osób. Z tego powodu Scrum nie nadaje się dla dużych projektów, gdzie wymagana jest koordynacja pracy kilkudziesięciu lub kilkuset ludzi. Duży problem pojawia się też gdy klient konkretnych rezultatów w bardzo konkretnym terminie. W wypadku Scrum’a nie ma dokładnych specyfikacji określających funkcjonalność produktu na przykład za pół roku. Prace odbywają się w sposób przyrostowy, co dwa tygodnie prezentowane są postępy i omawiane dalsze prace, często dochodzi do modyfikacji założeń. Z tego powodu klienci, którzy są nastawieni na konkretny termin i mają ściśle sprecyzowane wymagania, nie są zadowoleni z formy prezentacji wycen i proponowanych terminów.

W praktyce Scrum stosuje się do projektów, które nie mają ściśle określonych wymagań i tam gdzie klient chce na bieżąco modyfikować założenia w ramach reakcji na to co zostało już wykonane. Najczęściej wykonuje się tak projekty stratup’ów (firm wchodzących na rynek, które mają jakiś pomysł na biznes bez gotowego produktu), aplikacji mobilnych, platform społecznościowych itp. Produkty o wysokim stopniu skomplikowania czy specjalnych zastosowaniach (produkty bankowe, finansowe, aplikacje dla rządu, wojska czy dużych korporacji) najczęściej stawiają wymagania, którym Scrum nie może sprostać. Metodyki tradycyjne wychodzą na przeciw oczekiwaniom klienta, opisując dokładnie co zostanie stworzone i jak to będzie działać, już na etapie projektowania. Przygotowywana jest obszerna i bardzo dokładna specyfikacja funkcjonalna i techniczna, uzgadniane są terminy realizacji i oddania kolejnych etapów, warunki akceptacji itp. Tak szczegółowe opracowanie projektu niesie za sobą pewne ryzyko. Jakakolwiek zmiana musi przejść pełen proces akceptacji (zgłoszenie zmiany, przekazanie do działu projektowego, modyfikacja specyfikacji funkcjonalnych i technicznych, modyfikacja terminów i warunków akceptacji, zebranie zgód od osób odpowiedzialnych). Cały proces jest czasochłonny i w dużej mierze dzieje się poza zespołem odpowiedzialnym za implementacje. To warunkuje duży bezwład i w konsekwencji zagraża niedotrzymaniem terminów. Dodatkowo planowanie i projektowanie wszystkich szczegółów implementacji na samym początku projektu, zakłada duże ryzyko niedoszacowania czasu, czy błędna ocenę funkcjonalną lub techniczną. Oczekuje się w końcu od specjalistów umiejętności przewidzenia wszystkich najdrobniejszych nawet niuansów danego produktu. Jakakolwiek pomyłka na etapie projektowania prowadzi do problemów podczas implementacji a opisana wcześniej duża bezwładność i oderwanie procesu akceptacji zmian od zespołu, kończy się na przekroczeniach terminów lub budżetu.

Scrum powstał głównie jako propozycja rozwiązań tych słabych punktów procesów klasycznych. W Scrum’ies nacisk nie jest położony na jak najdokładniejszą i kompletną dokumentację – tu liczy się ciągła komunikacja podczas realizacji projektu, a ponieważ wszystkie osoby decyzyjne są zebrane w jednym zespole, nie występuje efekt bezwładności. Po każdym przebiegu propozycje zmian są wręcz oczekiwane, i PO może bardzo szybko uzyskać komplet informacji od zespołu na temat zaproponowanej przez niego zmiany i równie szybko zaplanować jej wdrożenie.

Podstawowe założenia AGILE:

• Oprogramowanie wytwarzane jest szybko by zapewnić satysfakcję klienta
• Działające oprogramowanie dostarczane jest w przyrostowy sposób i okresowo
• Podstawową miarą realizacji jest działające oprogramowanie
• Późne zmiany w specyfikacji nie mają destrukcyjnego charakteru na proces wytwarzania oprogramowania
• Kładzie się duży nacisk na współpracę na linii biznesu i IT, częste spotkania i zaangażowanie każdego w proces wytwórczy
• Bezpośredni kontakt jest najlepszą formą komunikacji.
• Prostota jest podstawowym wyznacznikiem procesu
• Zespoły są samozarządzalne
• Zmieniające się wymagania wymuszają regularną adaptację

SCRUM jest bardzo wiernym oddaniem idei Agile w konkretnej metodyce. Jego podstawowa zasada działania opiera się się w całości na 4 punktach manifestu.

Jak działa SCRUM

Ponieważ SCRUM wprowadza wiele nowych pojęć i określeń, zdecydowałem się na pozostawienie ich w wersji oryginalnej tj w języku angielskim. W kilku przypadkach korzystam z przyjętych polskich odpowiedników, ale tylko tam gdzie nie spowoduje to niejasności i złej interpretacji pojęć.

Scrum zakłada, że na początku (najlepiej jeszcze przed podpisaniem ostatecznej umowy) powoływany jest zespół. Składa się on z Product Owner’a, Scrum Master’a i Team’u. Product Owner (PO) jest przedstawicielem klienta w projekcie. Ma wiedzę i kompetencje pozwalające mu zaprojektować produkt i odbierać efekty prac, oceniając je pod katem przydatności i zgodności z wymaganiami. Product Owner w dużych firmach jest pracownikiem klienta, jednak często stosuje się praktykę delegowania pracownika wykonawcy do tej roli, z uwagi na dość specyficzne umiejętności i kompetencje które Product Owner musi posiadać.

Scrum Master (SM) jest specjalistą z dziedziny Scrum’a. Jego główną rolą jest szkolenie Product Owner’a z metodyki scrum, wyjaśnienie mu jego obowiązków i uprawnień. Jest też odpowiedzialny za projekt od strony zgodności z metodyką. Scrum Master dba by wszystkie elementy procesu były przestrzegane i ma prawo ingerować w prace zespołu jeśli widzi odchylenia.

Team to wszechstronna grupa pracowników wykonawcy. Jej główną cechą jest to, że posiada wszystkie kompetencje niezbędne do ukończenia danego produktu (najczęściej w skład team’u wchodzą programiści, analitycy, graficy, projektanci interfejsów, administratorzy itp. Ważne jest też to, że w team’ie nie ma podziału na stanowiska – zespół jest interdyscyplinarny i samoorganizujący się, nie posiada kierownika lub lidera, a role w zespole są wymienne i „wyłaniają się” samoczynnie. Oczekuje się, że każdy może wykonać każde zadanie jeśli ma takie kompetencje – nie jest więc niczym dziwnym, że jedna osoba może jednego dnia projektować interfejs a drugiego pisać kod, albo tworzyć szatę graficzną (wymagane są tylko umiejętności). Ideą jest tu jak najlepsze wykorzystanie zasobów.

Zespół (w znaczeniu Team + SM + PO) zaczyna pracę od opracowania listy wszystkich funkcjonalności tzw. User Stories (historyjek). Mają one postać kilkuzdaniowych opisów w formacie:

Jako {rola} chciałbym {akcja} poprzez wykorzystanie {obiekt}

na przykład:

Jako administrator chciałbym móc zablokować konto dowolnego użytkownika korzystając z panelu zarządzania użytkownikami.

Początkowo takie historyjki mają postać bardzo ogólną i w późniejszym etapie zespół rozbije je na bardziej szczegółowe elementy. Głównym dostawcą historyjek jest Product Owner, jako osoba mająca największą wiedzę o potrzebach klienta. Część historyjek może być dostarczona przez Team, jeśli wynika to z użytej technologii lub jest efektem burzy mózgów. Wszystkie historyjki muszą być zatwierdzone przez Product Ownera. Dodatkowo do listy historyjek przygotowywane są statyczne makiety interfejsów2 lub aktywne mockup’y całych stron produktu (tu dużo zależy od wykorzystanych narzędzi i umiejętności Product Ownera). Tak przygotowana lista nosi nazwę Product Backlog’u. Product Backlog jest prowadzony i zarządzany przez Product Owner’a. Product Owner przypisuje do historyjek priorytety, uwzględniając wymogi techniczne i opinię zespołu – jednak ostateczny głos należy do niego. Następnie Team wycenia każdą historyjkę, jeśli trzeba dzieląc ją na mniejsze historyjki, a te z kolei na konkretne zadania. Nie ma konieczności wyceny wszystkich historyjek z taką samą dokładnością, historyjki których wykonanie jest oddalone w czasie (niski priorytet) mogą być oszacowane z dużym przybliżeniem. Dokładna wycena obejmuje tylko historyjki z wysokim priorytetem które będą wykonywane w najbliższym czasie. Każdemu zadaniu przypisywana jest określona wartość punktowa, określająca stopień trudności i czasochłonność (wycena odbywa się w sposób subiektywny przez każdego z członków team’u, często wykorzystuje się tu sprawdzone sposoby jak choćby Planning Poker).

Team posiada cechę nazywaną szybkością (velocity), która określa optymalną ilość punktów, które mogą być zrealizowane podczas jednego Sprint’u (Sprint czyli przebieg, to cykliczny element procesu Scrum podczas którego realizowane są historyjki. Długość sprintu jest stała i określana na początku, najczęściej Sprint trwa 2 tygodnie). Podział, wycena i uszczegółowienie historyjek i stworzenie Product Backlog’u powinno wydarzyć się na spotkaniu inicjującym.

Po zakończeniu tego etapu prac, Product Owner wybiera listę historyjek do realizacji w pierwszym przebiegu. Suma punktów z tych historyjek nie może być wyższa niż szybkość zespołu. Rozpoczyna się pierwszy Sprint.

Nad poprawnością całego procesu stale czuwa Scrum Master, który może wskazywać ew. błędy i sugerować prawidłowy sposób postępowania (oczywiście tylko w zakresie metodologii). Zwłaszcza spotkanie inicjujące jest narażone na nieprawidłowości ponieważ zespół nie zdążył się jeszcze z sobą zżyć. W późniejszych etapach kiedy wykryte i usunięte zostaną najpoważniejsze błędy, rola Scrum Mastera polegać będzie już głównie na monitorowaniu. Dodatkowo Scrum Master pełni rolę kontrolera w codziennych pracach – pilnuje by wszystkie aspekty metodyki były przestrzegane i implementowane w prawidłowy sposób. Pełni też rolę skryby, zapisując notatki z organizowanych spotkań, notując uwagi nt. codziennych prac, które później przedstawi podczas podsumowania sprintu.

Poniższa tekst ma za cel przedstawić metodykę projektowania SCRUM oraz opisać zasady jej działania i efekty jakie przynosi. Całość zostanie opublikowana w trzech kolejnych częściach. Zapraszam do lektury.

Wstęp

Tworzenie oprogramowania jest procesem wysoce skomplikowanym i wymaga pewnego stopnia formalizacji dla zachowania zasady “złotego trójkąta” czyli odpowiednich proporcji Kosztów, Zasobów i Czasu w celu uzyskania Jakości.

W 99% przypadków oprogramowanie tworzone jest zespołowo, a tam gdzie zachodzi interakcja grupy ludzi w celu osiągnięcia wspólnego celu, należy ustalić zasady współpracy. Inżynieria oprogramowania zakłada istnienie różnych metodyk projektowych, ustalających sposób tworzenia oprogramowania, zasady pracy, wyszczególnia konkretne etapy i opisuje w jaki sposób pracować dla osiągnięcia wspólnego celu.

Przez wiele lat na tym polu niepodzielnie rządziły techniki “wodospadowe” takie jak PmBook, PMI czy PRINCE2. Zakładały one dość sztywne ramy formalne w których wyszczególniono kilka podstawowych etapów takich jak inicjacja, planowanie, wykonanie, monitorowanie, zakończenie. Te techniki, zwane ogólnie “twardymi” posiadają wady, które uwidaczniały się stopniowo wraz z czasem. Niska odporność tradycyjnych technik na zmiany w projekcie, czy to dotyczące specyfikacji, wymagań, terminów czy zakładanej konfiguracji systemu powodowały dużą trudność utrzymania w ryzach “złotego trójkąta” w skutek czego projekty były oddawane po czasie, przekraczały terminy lub były niskiej jakości.

Agile

Pierwsze działania zmierzające do zmiany dotychczasowych utartych zasad pracy, zostały podjęte w 1995 przez Ken’a Schwaber’a pod postacią ogólnych założeń metodyki SCRUM, która była pierwszą z tzw. “zwinnych” metodyk w tamtych czasach. Jednak prawdziwy wzrost popularności “agile” datuje się na rok 2001 i ogłoszenie tzw. Manifestu Agile przez grupę uznanych naukowców i działaczy świata IT (min. jeden z pomysłodawców Wikipedii, uznani twórcy metodyk projektowych, programiści, naukowcy itp..). Waga manifestu jest ogromna i należy ją przytoczyć dosłownie:

„We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

Podejście Agile zakłada przeniesienie punktu ciężkości na większości pól z „papieru” na człowieka - ważna jest komunikacja, reakcje interpersonalne, współpraca. W takim podejściu celem jest szybkie dostarczanie działających fragmentów aplikacji, pokazywanie klientowi przyrostu funkcjonalności i oczekiwanie od niego akceptacji lub zmian. Takie podejście w założeniu powoduje dużo większą zdolność adaptacyjną (ostatni punkt manifestu) i w efekcie pozwala w szybszy sposób reagować na zmiany, które i tak są nieuniknione.

Wczoraj udało mi się zrealizować w końcu plan aktywizacji mojej głównej domeny giergielewicz.pl. Przeprowadziłem domenę do docelowego miejsca zamieszkania na serwerach rootnode, skonfigurowałem zestaw aplikacji googla, między innymi pocztę, i w końcu mam “ładny” adres emailowy: michal w domenie giergielewicz.pl :)

Daje to całkiem fajne efekty. Google dostarcza pełny pakiet narzędzi do komunikacji, współpracy i publikacji. Możliwość podpięcia tych narzędzi pod swoją domenę jest naprawdę bardzo wygodną opcją i moim zdaniem każda platforma powinna mieć możliwość podłączenia swoich usług w taki sposób.

Niedługo zacznę importować do thumblra moje starsze posty publikowane jeszcze na platformie mobile.me Appla a ostatnio na facebook’u