W ostatniej notce opisałem marzenia grupki informatyków, spisane w Manifeście Zwinności. Marzenia te stoją w jawnej sprzeczności w stosunku, do tzw. twardych metodyk, bo:
- skoro ważniejsze są jednostki i interakcje, to procesy i narzędzia nie mogą nas krępować
- skoro ważniejsze jest działające oprogramowanie, to pisanie obszernej dokumentacji nie może zanadto obciążać
- skoro ważniejsza jest współpraca z klientem, to istotnijszy jest sposób prowadzenia projektu od negocjacji ścisłych ram kontraktu
- skoro ważniejsze jest nadążanie za zmianami, to plan nie może być sztywny, aby można było reagować na zmiany
Kiedy opowiadałem o Manifeście Zwinności na seminarium w 2003 roku, to programiści z pewnej firmy potraktowali mnie jak heretyka, a dyskutując ze mną uzyli niepodważalnego argumentu "tak się nie da robić projektów!". I rzeczywiście: wielkie koncerny wydające środowiska programistyczne (Microsoft, Borland) dość późno się zorientowały w tym, że można inaczej, a gdy już się zainteresowały, to zaczęły na potęge popularyzować słowo Agile, które to stało się słowem modnym. I tak: Microsoft opublikował Microsoft Solution Framework for Agile System Development, a Borland swoje Software Delively Optimization, a nawet otrzymał nagrodę za przekształcenie całej swojej organizacji w Agile. Poniżej wykres Google.pl/trends dotyczący popularności "agile manifesto", jak widać popularność wystrzeliła w górę w czwartym kwartale 2006 roku.
Jednakże nawet zwinne grupki programistów powinny przestrzegać jakichś zasad, bo każde współczesne oprogramowanie wymaga jakości. Jak tą jakość zapewnić? Ano jakąś metodyką, tylko tym razem zwinną. Do takich metodyk należy eXtreme Programming (XP), która została opisana przez Rona Jeffries. Kenta Beck a w książce "Extreme programming explained: Embrace change" wydanej w 1999 roku.
Jedną z podstawowych praktyk XP jest ciągły kontakt z klientem, który (jako najlepiej wiedzący czego chce) jest członkiem zespołu - uczestniczy w projekcie, dzięki czemu kontroluje go oraz ma wpływ na jego rozwój. Jednym z obowiązków takiego zespołu programistycznego jest częsta (najlepiej: codzienna) kompilacja kodu i publikowanie go dla pracowników klienta tak, aby mogli go testować, oceniać i dawać konkretne propozycje przyszłych zmian oraz aby już na wstępnym etapie mieli możliwość zgłaszania popełnionych błędów).
Łatwo zauważyć, że pracując w ten sposób można uniknąć pomyłki opisanej w notce 20. Jaką metodyką pisać program. Można też zauważyć, że gdy spojrzymy na tworzenie systemu jak na drzewo decyzyjne, to znajdując się w jakimś węźle tego drzewa, możemy w dowolnej chwili zawrócić, a zmiany są naprawdę łatwe do realizacji, bo są na tym etapie jeszcze drobne.
Można powiedzieć, że każdy taki węzeł tego drzewa jest tak naprawdę pewnym życzeniem wykonania zmiany w systemie (więc nie TAK/NIE, a konkretną specyfikacją). Takie życzenie klient może wyrazić bardzo prosto - wystarczy, aby odbiorca tego życzenia był w stanie je zrozumieć. Takie życzenie może wyglądać tak:
Albo np. tak:
Każde takie życzenie powinno być zapisane na jednej "kartce" i wrzucone do "worka".
Łatwo sobie wyobrazić ogromną ilość takich "kart życzeń" w "worku". Trzeba jeszcze nadać jakichś mechanizm kontroli tych kart. Dlatego, każda karta ma przypisaną sobie datę zgłoszenia oraz osobę zgłaszającą, potem ktoś (np. menadżer projektu) "stempluje" taką kartę jako "zaakceptowaną" do wykonania, a jeszcze inna osoba "stempluje" oznaczając ją jako "wykonaną", jeszcze ktoś inny "zatwierdza", a na końcu następuje "podstemplowanie" jako "rozliczona".
"Worek" to oczywiście tylko symbol, bez systemu informatycznego zarządzającego projektem (np. FogBugz) się nie obejdzie. Najlepiej, jeżeli system umożliwia odbieranie emaili (wtedy każda pojedyncza karta jest przesyłana przez pracownika klienta pojedynczym emailem) i ląduje w systemie.Wtedy łatwo śledzić historię zmian stanów takich kart, łatwo wykonywać różnego rodzaju zestawienia (np. globalny dotyczczasowy czas pracy nad projektem, czy pozostały szacowany czas).
Łatwo zauważyć, że w mojej notce promuję "zarządzany chaos", gdzie każdy uczestnik projektu ma prawo zgłoszenia poprawki do realizowanego projektu. Ot, jest to coś podobnego, co ogłosił Obama, gdy wezwał pracowników instytucji federalnych do zgłaszania propozycji racjonalizatorskich. Ciekawe czy tam też zgłasza się takie propozycje emailem ;) Ok, spójrzmy teraz jak wygląda projekt, na który składają się wrzucane do "worka", "karty życzeń":
Czy widać już, że tak można bez końca? A w którym momencie możemy powiedzieć, że realizowany przez nas dla klienta system informatyczny spełnił oczekiwania? Ano przydałoby się jeszcze podzielić te karty w jakieś sensowne małe wydania - produkty, z których każdy powinien mieć przydzielone następujące atrybuty: oczekiwane rezultaty, na kiedy, za ile, jakie kryteria akceptacji, a wtedy każdy z tych produktów nadaje się do rozliczenia z klientem. Innymi słowy, sponsora projektu interesują tylko takie czarne skrzynki - produkty, a nie interesują karty życzeń.
W kolejnej notce napiszę jak ulepszyć samo pisanie programów (tzn. przyspieszyć kodowanie i zarazem zapewnić jego jakość).
Komentarze
Pokaż komentarze (1)