o modelowaniu procesów i systemów 

O tym, że modelowanie jest przydatne w projektowani wszelakich aplikacji, nie trzeba przekonywać nikogo. Cieszy mnie bardzo, gdy widzę, że kolejne firmy mają ten sam pogląd i razem wypracowujemy metodykę działania dla ich potrzeb. Tak też było w ostanie dni maja, w które prowadziłem szkolenie dla kilku osób z  firmy produkującej gry.  Bardzo dobrze spędziłem ten czas z dwóch powodów. Po pierwsze już dawno nie miałem tak wdzięcznego tematu do pracy. Po drugie uczestnicy – rzeczowi, wymagający, doświadczeni programiści poszukujący rozwiązań szytych na ich miarę, co spowodowało, że szkolenie było bardzo intensywne i myślę, że udane. Świadczą o tym ankiety, w których otrzymałem same bardzo dobre oceny za ważność poruszanych tematów, ćwiczenia i moje przygotowanie. Na koniec cytat z ankiety z punktu Co najbardziej podobało Ci się w niniejszym szkoleniu: “Duża liczba ćwiczeń praktycznych. Szkolenie zostało dostosowane do dziedziny jaką się zajmujemy”. Dziękuję za te słowa.

Mit: Zwinne zespoły nie produkują dokumentacji

Fakt: Dobry zwinny zespół produkuje taką ilość dokumentacji, która jest niezbędna do wspierania, utrzymania i rozwoju oprogramowania. Zwinne zespoły produkują przykładowo dokumentacje wyjaśniającą metafory i pojęcia słownikowe używane w trakcie projektu oraz modele w ograniczonym zakresie.

Mit: Zwinne zespoły nie potrzebują inwestować w wymagania

Fakt: Zwinne zespoły maniakalnie koncentrują się na spotkaniach z klientem związanych z określeniem wymagań. Nie potrzebują zapisywać wszystkiego na przód. Jeśli nie ma na miejscu klienta, zespoły używają bardziej tradycyjnych technik, takich jak przypadki użycia.

Mit: Zwinne zespoły nie tworzą modeli ani architektury systemu

Fakt: Zespoły tworzą wiele modeli (zazwyczaj ręcznie na białych kartach) w celu ułatwienia komunikacji. Badania wykazały, że większość zwinnych zespołów wykonuje modele by pomóc zrozumieć jak oni budują i konstruują system. Brak projektu całości na początku przedsięwzięcia nie oznacza braku projektowania. Najczęściej obok przypadków użycia powstają diagramy klas i aktywności.

Mit: Zwinne zespoły nie maja żadnych planów

Fakt: Zwinne zespołu projektują by nie było jak z Alicją w Kainie Czarów Lewisa Carrolla:

– Czy nie mógłby pan mnie poinformować, którędy powinnam pójść? – mówiła dalej.
– To zależy w dużej mierze od tego, dokąd pragnęłabyś zajść – odparł Kot – Dziwak.
– Właściwie wszystko mi jedno.
– W takim razie również wszystko jedno, którędy pójdziesz.
– Chciałabym tylko dostać się dokądś – dodała Alicja w formie wyjaśnienia.
– Ach, na pewno tam się dostaniesz, jeśli tylko będziesz szła dość długo.

Mit: Zwinne zespoły szybko przestają być kontrolowane, robią cokolwiek jak lubią i kiedy chcą.

Fakt: Zespół jest właściwie bardzo zdyscyplinowany i bardzo skupiony.Zadania zawsze są wykonywane w ustalonym porządku, z priorytetem określonym przez klienta  przy pomocy przypadków użycia. Mierzenie osiągnięć celów nakreślonych przez przypadki użycia służy do jasnego oszacowania postępu i wydajności.

Mit: Jeśli jesteś zwinny, to nie potrzebujesz żadnych menadżerów

Fakt: Potrzebny jest menadżer by utworzyć dobre środowisko pracy i zaplanować iteracje w oparciu o przypadki użycia. Zwinny zespół dostarcza mierzalnych celów, określonych przez przypadki użycia. Menadżer za pomocą przypadków użycia szacuje ryzyko co umożliwia mu tym samym bardziej efektywne zarządzanie.

W dniach 7-8  maja prowadziłem w Warszawie szkolenie z projektowania systemów informatycznych. Nikt z uczestników szkolenia nie miał wątpliwości, że modele w UML są przydatne a jednocześnie metodyki z nurtu Agile odrzucają modelowanie. Oczekiwania wobec szkolenia krążyły wobec tematów co i jak dokumentować w UML? Jak obszerną dokumentację wykonywać? Jak połączyć modelowanie w UML z zwinnymi (ang. Agile) metodykami takimi jak XP czy Scrum.  W trakcie szkolenia zaprezentowałem istotę metodyk zwinnych i ciężkich oraz zaprezentowałem klucz -  łącznik pozwalający na połączenie modeli wyrażonych w UML z zwinnym podejściem. Wskazałem także jak zaprezentowane rozwiązanie może dodatkowo pozwolić na lepsze wymiarowanie projektu np.: w zakresie ustalenia zakresu iteracji – sprintu jak to mówią wyznawcy Scrum.

Wydaje mi się, że szkolenie spełniło oczekiwania jego uczestników o czym świadczą ankiety: w zakresie sposobu prezentacji tematu, przydatności szkolenia  i mojego przygotowania otrzymałem same dobre i bardzo dobre oceny. Dziękuję szczególnie za jedną opinię w punkcie: “Co się Państwu najbardziej podobało w niniejszych warsztatach?”, która brzmi “Kompetencja prowadzącego i sposób prowadzenia szkolenia”.

Włodzimierz Dąbrowski, Andrzej Stasiak, Michał Wolski

Seria: W praktyce
Wydawnictwo Naukowe PWN
Warszawa, 2007 r.
ISBN: 978-83-01-15251-2
Wydanie: pierwsze
Objętość: s. 308
Format: 16,5×24 cm
Oprawa: miękka

Książka przedstawia sposób modelowania systemów informacyjnych z wykorzystaniem podejścia obiektowego i języka UML 2.1. Czytelnik znajdzie w niej współczesne spojrzenie na modelowanie i projektowanie systemów informatycznych w ujęciu obiektowym zilustrowane praktycznymi przykładami wykorzystania języka UML w różnorodnych obszarach.

W książce zgromadzono wiedzę najlepszych praktyk oraz często popełnianych przez projektantów błędów. Pozwoliło to na zbudowanie unikatowego repozytorium obszernej wiedzy z zakresu modelowania za pomocą języka UML. Najważniejszą zaletą książki “Modelowanie systemów informatycznych w języku UML 2.1 w praktyce” jest skoncentrowanie się autorów na praktycznych aspektach wykorzystania języka UML. Autorzy prezentują w niej zastosowania tego języka w różnych obszarach, od projektowania systemów czasu rzeczywistego poprzez projektowanie baz danych aż po modelowanie systemów biznesowych.

Książka skierowana jest przede wszystkim do studentów kierunków informatycznych oraz kierunków ekonomicznych i zarządzania mających w programie modelowanie biznesowe i projektowanie systemów informacyjnych oraz do praktyków pracujących przy tworzeniu systemów informatycznych. Może być też przydatna jako pomoc przy prowadzeniu kursów i szkoleń z zakresu modelowania biznesowego i projektowania systemów w języku UML.

Książkę można zakupić w księgarni Argon: