Od czasu do czasu wpadają mi do skrzynki email „niuslettery”, które gdzieś tam czasem zamawiam, głównie z powodów poznawczych. Oto jeden z nich…
Nie jest tajemnicą, że na rynku mamy różne metody pracy i wszystkie mają swoich zwolenników i przeciwników czy może raczej krytyków. Tym razem przedmiotem „badania” był sposób opisania problemu i wnioski jakie autor wyciągnął.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
W ostatnim artykule zwracałem uwagę między innymi na bardzo ważny element analizy i projektowania jakim jest abstrahowanie od detali, ponieważ:
…analityk musi abstrahować od wszelkich detali, bez tego projekt zostanie już na samym początku ?zabity? ich ilością. [1]
Nieco wcześniej (2013 r.) pisałem o tym, kiedy uzgadniać detale, które i gdzie one są:
Cała logika biznesowa jest wykonywana wewnątrz aplikacji (informacje o ewentualnych błędach pojawią się po zatwierdzeniu formularza), np. upust może być sprawdzony (albo naliczony) dopiero po skompletowaniu danych wymaganych do jego wyliczenia, czyli będzie to kilka różnych pól (najmniej dwa :)). Bywa, że do wyliczenia czegoś potrzebne będą dane nie wprowadzane do danej formatki faktury, np. saldo klienta. [2]
Tym razem kilka słów o tym jak skomplikować i zabić projekt już pierwszego dnia. Jednym z najbardziej ryzykownych sposobów rozpoczynania projektu jest rozpoczynanie od konsultacji z użytkownikiem w kwestii interfejsu użytkownika. Prowadzi to do sytuacji, w której jeszcze nie mamy żadnego pojęcia o logice biznesowej i architekturze aplikacji, a już deklarujemy to jak będzie się ona komunikowała z użytkownikiem (ciekawe na jakiej podstawie?).
Do napisania tego artykułu skłonił mnie ten wpis:
The role of design still puzzles many agile teams I work with. When should the design activities take place? Who should carry them out? How are design decisions best captured? This blog tries to answer the questions by discussing a user-centric, iterative, and collaborative design process for Scrum and Kanban teams. [3]
Autor pokazuje jak „walczy” ze złożonością na tym etapie, ja pragnę zasugerować by do tej złożoności na tym etapie po prostu nie dopuszczać. Powyższy diagram pokazuje z czym walczy analityk, który doprowadzi do zebrania wyrwanych z kontekstu (tak, nie ma modelu logiki więc dyskusje o GUI są oderwane od kontekstu) „wymagań” (historyjki użytkownika, lewa kolumna tablicy Story Area), których zamawiający może „naopowiadać” bardzo dużo.
A jak inaczej? Pomoże nam stosowanie wzorców architektonicznych. Są one od lat dostępne w większości frameworków (szkoda, że bardzo często developerzy je ignorują). Poniżej prosty, abstrakcyjny model klasycznego wzorca MVC.
W architekturze wydziela się komponenty (separowanie odpowiedzialności): odpowiedzialny za obsługę dialogu z użytkownikiem (View), odpowiedzialny za technologie, jakość, bezpieczeństwo, sterowanie itp. (Controler) oraz odpowiedzialny za (całą a nie tylko dane!) logikę biznesową (Model).
Zarządzanie złożonością polega tu na tym, by na początku analizy i projektowania abstrahować całkowicie od detali GUI! (a dokładnie od całej technologii czyli elementów View i Contoler). Kluczową odpowiedzialnością aplikacji jest realizacja określonej logiki biznesowej. Na tym etapie powinien powstać model przypadków użycia rozumiany jako prosty dialog pomiędzy użytkownikiem a aplikacją, tu celem jest uchwycenie kluczowych wymagań jakimi są wymagane usługi aplikacyjne realizowane przez aplikację oraz opracowanie wewnętrznej architektury – Modelu, która te usługi zrealizuje. Dopiero po przetestowaniu całej logiki biznesowej na modelach, warto się zabierać na komplikowanie projektu poprzez opracowanie detali GUI, sterowania, bezpieczeństwa itp.. Postępowanie takie umożliwia wzorzec architektoniczny MVVM opracowany ponad 10 lat temu. Wzorzec ten wprowadza dodatkowy komponent pomiędzy komponenty View i Model: View-Model, który realizuje logikę dialogu GUI-użytkownik. Dzięki temu możemy wydzielić etap pracy nad GUI, jako osobny w projekcie, który zrealizuje (później) tak zwany „UX designer”, a developer zamieni pierwotnie abstrakcyjny komponent View na implementacje „View-View Model”.
Bardzo dobry opis tego podejścia:
W przypadku warstwy prezentacji można wykorzystać m. in. następujące rozwiązania: MVC, MVP czy Model-View-ViewModel. Ze względu na mechanizm wiązań (binding), programistom WPF oraz Silverlight, polecany jest wzorzec MVVM ? jest to technologia umożliwiająca bardzo łatwą implementację wzorca. […] …po co utrudniać sobie zadanie poprzez wykorzystywanie MVVM, zamiast pisać aplikację w klasyczny sposób (za pomocą code-behind)? W końcu wdrożenie praktycznie każdego wzorca projektowego wymaga trochę większych początkowych nakładów pracy.
Podejście Code-Behind (autonomous view ? AV) ma poważną wadę ? nie gwarantuje elastyczności oraz testowalności. Podsumowując, wprowadzenie wzorca [MVVM, przypis autora] umożliwia:
niezależność logiki od sposobu wyświetlania danych,
niezależność kodu od technologii, w której wykonana jest warstwa prezentacji,
wykonywanie testów ? za pomocą MVVM czy MVP możliwe jest wykonanie testów zautomatyzowanych (np. jednostkowych),
łatwą zamianę widoków (brak sztywnych powiązań między widokiem a logiką).[4]
(Tak: stosowanie wzorców podnosi początkową pracochłonność ale zwraca się z nawiązką w dalszych cyklach życia projektu.) Strukturę i historię powstania tej architektury zainteresowani mogą poznać także tu:
Model View View Model (MVVM) In 2005, John Gossman, Architect at Microsoft, unveiled the Model-View-ViewModel (MVVM) pattern on his blog. MVVM is identical to Fowler?s Presentation Model, in that both patterns feature an abstraction of a View, which contains a View?s state and behavior. Fowler introduced Presentation Model as a means of creating a UI platform-independent abstraction of a View, whereas Gossman introduced MVVM as a standardized way to leverage core features of WPF and Silverlight to simplify the creation of user interfaces. MVVM is a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms to leverage core features of WPF such as data binding, commands , templates.
This diagram take from MSDN depicts MVVM Pattern in action.
[5]
Tak więc analizę i projektowanie warto zacząć od logiki i szkieletu architektury, a ta to przede wszystkim Model (dziedziny) systemu czyli kompletna logika biznesowa (utożsamianie modelu dziedziny z relacyjną bazą danych to poważny błąd i nieporozumienie). Po uporaniu się z tym etapem projektu ma sens opracowywanie detali komunikacji z użytkownikiem, bo dopiero teraz znamy wymagania i ograniczenia logiki biznesowej. Odkrywanie ich dopiero na etapie prototypowania to stanowczo za późno, bo generuje to ogromne koszty cyklicznego refaktoringu kodu (albo kod szybko staje się „bryłą błota”).
Bardzo często słyszę, że klient chce jak najszybciej coś zobaczyć. Rzecz w tym, że jeżeli się na to zgodzimy, powstaje i jest akceptowana masa tak zwanych „pobożnych życzeń”, a klient bardzo szybko się przywiązuje do tego co zobaczył na prezentacji (i nie chce odpuścić). W efekcie tworzy się spirala żądań, testów i poprawek, które szybko przekształcają „agile” w porażkę budżetu i harmonogramu. Praktyka pokazuje, że budżet zawsze ma limit, dlatego bardzo wiele takich projektów kończy albo w koszu na śmieci albo efekty stanowią tylko namiastkę tego co opisywała pierwotna wizja. Jeżeli zaś zaczniemy od jądra systemu a na koniec zostawimy sobie „makijaż” jakim jest GUI, szansa na sukces będzie znacznie większa. Problem polega na tym, że moda na „user-centric, iterative, and collaborative design” jest silna mimo tego, że jest przyczyną wielu porażek.
Tak więc odpowiedź na pytanie jak poradzić sobie z życzeniami biznesu, brzmi: nie dopuszczać do ich wyartykułowania :). Projektowanie i tworzenie samochodu rozpoczyna się od podwozia i napędu a nie od deski rozdzielczej…
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Polecam lekturę ciekawej Opinii Prawnej kancelarii Maruta Wachta sp. j.. (dalej odpowiednio Opinia i Kancelaria) na temat MOŻLIWOŚCI I SPOSOBU WYKORZYSTANIA METODYKI AGILE W PROJEKTACH INFORMATYCZNYCH REALIZOWANYCH Z ZASTOSOWANIEM USTAWY ? PRAWO ZAMÓWIEŃ PUBLICZNYCH.
Kluczowe pojęcia i definicje
Zanim się odniosę do Opinii, najpierw klika słów na temat zwinnego realizowania projektów. Jak rzadko, posłużę się Wikipedią, gdyż pojęcie „metody zwinne” nie ma ścisłej definicji, Manifest Agile zaś jest na tyle ogólny, że nie jest możliwe użycie go jako definicji. Po drugie Wikipedia jest powszechnie przywoływana jako źródło w środowiskach związanych ze stosowaniem metod zwinnych dlatego uznałem, że definicje tam umieszczane będą tu najbardziej adekwatne. Przypomnę, że osobiście nie używam pojęcia „agile” w swoich projektach, gdyż uważam, że obecne słownictwo i metody w obszarze inżynierii zupełnie wystarczą i są znacznie precyzyjniejsze i od lat stosowane z powodzeniem. Poniżej próba uporządkowania tych pojęć na potrzeby dalszych rozważań.
Za Wikipedią (cytaty):
Programowanie zwinne (ang. agile software development) ? grupa metod wytwarzania oprogramowania opartego na programowaniu iteracyjno-przyrostowym, powstałe jako alternatywa do tradycyjnych metod typu waterfall. Najważniejszym założeniem metodyk zwinnych jest obserwacja, że wymagania odbiorcy (klienta) często ewoluują podczas trwania projektu. Oprogramowanie wytwarzane jest przy współpracy samozarządzalnych zespołów, których celem jest przeprowadzanie procesów wytwarzania oprogramowania. Pojęcie zwinnego programowania zostało zaproponowane w 2001 w Agile Manifesto.
Komentarz: rynek się zmienia w coraz szybszym tempie, otoczenie rynkowe wpływa na organizacje, te zaś pod jego wpływem zmieniają swoje strategie i taktyki. Jeżeli oprogramowanie jest ich narzędziem pracy, to zmiany te przeniosą się wymagania wobec tego oprogramowania. Jest to nieuniknione. Nie jest to „ewolucja wymagań” a ich naturalny cykl życia (pomijam tu kwestie zmiany pomysłów po stronie zamawiającego, ale to inny temat).
Generalnie grupa metodyk oparta jest na zdyscyplinowanym zarządzaniu projektem, które zakłada częste inspekcje wymagań i rozwiązań wraz z procesami adaptacji (zarówno specyfikacji jak i oprogramowania). Najczęściej znajdują zastosowanie w małych zespołach programistycznych, w których nie występuje problem komunikacji, przez co nie trzeba tworzyć rozbudowanej dokumentacji kodu. Kolejne etapy wytwarzania oprogramowania zamknięte są w iteracjach, w których za każdym razem przeprowadza się testowanie wytworzonego kodu, zebranie wymagań, planowanie rozwiązań itd. Nastawiona są na szybkie wytwarzanie oprogramowania wysokiej jakości.
Niestety ten fragment opisu agile mówiący o dyscyplinie i częstym przeglądaniu stanu prac samorzarządzalnych zespołów przywodzi na myśl stary żart o tym, że herbata robi się słodka nie od cukru a od mieszania. Tu ważne jest słowo „planowanie” a także „zebranie wymagań”. Minus jest taki, że zbieranie iteracyjne wymagań oznacza, że odkrywane są one dopiero w toku realizacji projektu.
Skład zespołów jest zazwyczaj wielofunkcyjny oraz samozarządzalny, bez zastosowania jakiejkolwiek hierarchii organizacyjnej. Członkowie zespołu biorą odpowiedzialność za zadania postawione w każdej iteracji. Sami decydują jak osiągnąć postawione cele.
Metodyki zwinne dużą wagę przywiązują do bezpośredniej komunikacji między członkami zespołu, minimalizując potrzebę tworzenia dokumentacji. Jeśli członkowie zespołu są w różnych lokalizacjach, to planuje się codzienne kontakty za pośrednictwem dostępnych kanałów komunikacji (wideokonferencja, e‑mail itp.).
Tu poważaną wadą jest „niechęć” do tworzenia dokumentów. Skutkuje to ogromnymi problemami z odtwarzaniem „ustaleń” historycznych (już choćby cofnięcie się o jedną iterację wstecz bywa problemem, bo nie ma śladu po treści ustaleń, a pamięć ludzka jest jednak ograniczona).
Częstym błędem występującym u osób i zespołów stosujących metodykę agile jest nadinterpretacja jej założeń i całkowicie błędne pomijanie bardzo ważnych etapów projektu tj. „zbierania wymagań”, a następnie na ich podstawie „analizy” oraz „planowania”. (Źródło: Programowanie zwinne ? Wikipedia, wolna encyklopedia)
Tu, mam nadzieję, autorzy mieli jednak na myśli jakieś dokumenty.….
Tak więc są podstawy by uznać, że obecnie metody zwinne:
znajdują zastosowanie w małych zespołach programistycznych.
członkowie zespołu sami decydują o sposobie realizacji projektu.
są etapy zbierania wymagań, analizy, planowania jednak nie sprecyzowano co i w jakiej postaci zawierają te „dokumenty”.
nadal „raczej”, poza kodem, nie powstaje żadna dokumentacja.
Kolejny ważny termin to SCRUM:
Scrum – iteracyjne i przyrostowe ramy postępowania zgodne z manifestem Agile. W ramach tego postępowania rozwój produktu podzielony jest na mniejsze, trwające maksymalnie jeden miesiąc kalendarzowy iteracje, zwane sprintami następującymi bezpośrednio po sobie. Po każdym sprincie zespół pracujący nad rozwojem produktu jest w stanie dostarczyć działającą jego wersję. Scrum jest często stosowany podczas tworzenia i rozwijania oprogramowania, nie jest jednak ograniczony tylko do tej dziedziny. Ogólne założenia podejścia zostały zaprezentowane przez Hirotakę Takeuchiego i Ikujiro Nonakę w artykule The New Product Development Game, opublikowanym w Harvard Business Review w styczniu 1986 roku. Definicja Scruma w zastosowaniu do produkcji oprogramowania została sformalizowana przez Kena Schwabera w 1995. Scrum często omyłkowo nazywany jest metodyką. (Źródło: Scrum ? Wikipedia, wolna encyklopedia).
SCRUM to „ramy postępowania”, nie jest to „metodyka” (metodyka to „zbiór zasad dotyczących sposobów wykonywania jakiejś pracy lub trybu postępowania prowadzącego do określonego celu”), jednak stanowi sobą opis zarządzania realizacją projektu.
Popatrzmy na inżynierię oprogramowania jak na inżynierię w ogóle. Generalnie coś co ma konstrukcję, architekturę, mechanizm działania i funkcjonalność jest produktem „inżynierii”. Słownik j.. polskiego mówi, że:
inżynieria: projektowanie i konstruowanie obiektów oraz urządzeń technicznych
Tak więc mamy dwa kluczowe etapy procesu tworzenia: projektowanie i konstruowanie. Podsumowując mamy prawo uznać, że tworzenie oprogramowania, jeżeli uznamy ten proces za inżynierię oprogramowania, składa się z projektowania i konstruowania (kodowania).
W 2013 roku pisałem:
Pamiętajmy, że zarządzanie zakresem projektu jest tym kosztowniejsze im więcej szczegółów ten zakres posiada. Projekt o 30 wymaganiach vs. projekt o 300 wymaganiach to nie projekt o 10-krotnie większym koszcie, ta różnica będzie znacznie większa (pomijam to, jak w ogóle zdefiniujemy wymaganie) (Źródło: Mega projekty czyli jak zjeść słonia | | Jarosław Żeliński IT-Consulting).
Artykuł ten zawiera także dwa diagramy: tak zwany wodospadowy oraz iteracyjno-przyrostowy, sposób zarządzania zakresem projektu.
Projekt mający jeden etap analizy i projektowania.
Projekt w którym na początku projektuje się architekturę a szczegóły doprecyzowuje się w toku kolejnych etapów (iteracji).
Drugi diagram to właśnie w inżynierii iteracyjno-przyrostowe wytwarzanie (także oprogramowania). Jeżeli produkt jaki ma powstać jest „mały” sprowadzi się praktycznie do pierwszych dwóch części: analiza i opracowanie architektury oraz projektowanie i realizacja. Jeżeli projekt (zakres) jest na tyle duży, że ryzyko projektowania całości jest zbyt duże (patrz pierwszy diagram), należy wybrać metodę iteracyjno-przyrostową, jednak wymaga to na początku zawsze opracowania (zaprojektowania) wizji całości, jaką jest architektura komponentowa całego rozwiązania a przy najmniej strategia tworzenia aplikacji. Co tu jest opisem przedmiotu zamówienia (OPZ)? OPZ – dla dokonania wyceny – musi mieć skończony zakres, musi stanowić coś co pozwoli na „odbiór produktu”. Dlatego dla dużych projektów wygodnie jest opracować w ramach OPZ:
Z taką dokumentacją mamy: zakres projektu oraz narzędzie do zarządzania iteracjami: każdy kolejny etap to jeden przypadek użycia. Powinno więc być możliwe stworzenie dokumentu OPZ mającego zamknięty zakres, metodę rozliczenia (odbiór jako testy przypadków użycia) i otwartą drogę dla pracy „zwinnego” zespołu, czyli miejsce na kolejne iteracje projektowania detali implementacji.
Dokument ma dla wygody ponumerowane akapity, odniosę do wybranych z nich (sekcja Wnioski):
(1) Kancelaria odnosi się bardzo ogólnie do agile, potwierdzając brak ścisłej definicji, niestety nie tworzy własnej na użytek Opinii.
(2) Kancelaria wyraża opinię, że metody te „są coraz powszechniej wykorzystywane, z powodzeniem, na kontynencie amerykańskim oraz w Europie Zachodniej”, niestety brak ścisłej definicji agile oraz brak kryteriów „powodzenia projektu” (z jednaj strony powodzeniem jest projekt ukończony przy zgodzie obu stron umowy, z drugiej projekt w którym w terminie i budżecie wykonano deklarowany zakres) nie pozwala ocenić tego wniosku, jest to niestety spekulacja autorów Opinii.
(5) Kancelaria pisze, że ” Zasadnicze znaczenie ma w szczególności świadoma akceptacja przez zespół zamawiającego decyzji o realizacji danego projektu w omawianej formule [mój przyp.: nie zdefiniowano tej „formuły”] oraz konsekwencji z tego płynących”, jednak moja uwaga: interes Zamawiającego to maksimum korzyści osiągnięty najniższym kosztem, rynkowy interes Wykonawcy jest dokładnie przeciwstawny, z tego powodu nie wyobrażam sobie takiego projektu bez dokumentacji, która na początku opisuje „Przedmiot Zamówienia”, nie może nim być jednak „edżajlowa usługa podjęcia starań”…
(6) tu Kancelaria zwraca jednak uwagę, że zwinne metody można stosować do projektów „takich, których wartość jest niższa niż tzw. progi unijne lub takich, w których zastosowanie znajduje określone wyłączenie stosowania przepisów Prawa zamówień publicznych”.
(7) ochrona prawna (Krajowa Izba Odwoławcza, sądy) moim zdaniem nie jest tu problemem, problemem jest jakość dokumentacji technicznej, bo pojawienie się sporu w pierwszym rzędzie zaowocuje żądaniami opinii rzeczoznawców a nie prawników. Niestety z mojego doświadczenia wynika, że rzeczoznawcy w tej branży rzadko mają kompetencje z zakresu inżynierii oprogramowania.
Opinia zawiera bardzo cenną część: Podstawa prawna, która niestety jednak nie zawiera bardzo ważnego w moich oczach odniesienie do ochrony know-how (Dz.U. 1993 Nr 47 poz. 211 USTAWA z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji), choćby z uwagi na to, że spółki skarbu państwa podlegają pod PZP i są podmiotami rynkowymi chroniącymi swoje tajemnice (więcej o tym napisałem w artykule Ochrona Know-how Zamawiającego).
Porównanie metody kaskadowej i Agile
(1) Jestem tu zaskoczony przyjętą przez Kancelarię definicją «kaskadowy” (tu autorom Opinii i czytelnikom tego tekstu gorąco polecam tę uznaną już na świecie pozycję: SYSTEM ANALYSIS AND DESIGN Fifth Edition). To co nazywamy „waterfall” to nie kaskadowy proces a proces dwuetapowy: analiza i szczegółowe projektowanie oraz implementacja projektu. Zacytuję powyższą pozycję literatury przedmiotu:
Waterfall development methodologies have the advantages of identifying requirements long before programming begins and limiting changes to the requirements as the project proceeds. The key disadvantages are that the design must be completely specified before programming begins, a long time elapses between the completion of the system proposal in the analysis phase and the delivery of system, and testing is treated almost as an afterthought in the implementation phase.
(13) powołanie się na użycie Agile w Alegro nie do końca jest tu rzetelne. Na jednej z konferencji (Quality of IT, 7 – 8 2015 r.) referat Szefa IT Allegro nie potwierdza tego. Owszem odeszli od klasycznego „waterfall” z powodów jak wyżej, jednak wdrożenie agile doprowadziło ich na skraj katastrofy i wdrożono metody iteracyjno-przyrostowe w tym planowanie, dokumentowanie i zarządzanie zmianą.
(17) Kancelaria pisze: „Zgodnie z zasadami metodyki Agile, produkty w projekcie były dostarczane małymi częściami, po krótkich iteracjach (co do zasady trwających 3 tygodnie).” Problem w tym, że każdy doświadczony inżynier powie, że nie jest możliwe sprowadzenie każdej dużej konstrukcji inżynierskiej do komponentów, których wytworzenie zmieści się w trzytygodniowym odcinku czasu. Ta zasada (3 tyg. sprinty) nie tylko mnie wprawa w zakłopotanie bo np. zapewne można w trzy tygodnie stworzyć stronę która posłuży to wypełniania wniosków o polisę czy kredyt, ale stworzenie w 3 tyg. komponentu scoringowego, przydatnego do oceny zdolności kredytowej wnioskodawcy jest niemożliwe a oddanie do użytku, po 3 tyg. „niekompletnego” takiego modułu raczej przyniesie szkody niż „korzyści dla klienta” (ta uwaga dotyczy także następnej sekcji Możliwość podziału produktu na krótkie fazy, (3) str. 30).
Nie podważam tego, że użycie „agile” prowadziło gdzieś do sukcesów, jednak bez zdefiniowania pojęcia „sukces” projektu, taka ocena jest bezwartościowa, bo sam fakt, że projekt w końcu został doprowadzony do końca nic tu nie znaczy, liczy się to jak się miał pierwotny plan do uzyskanego efektu a tego tu nie napisano.
Nie była tu moim celem ocena tego opracowania. Celem jest konfrontacja opisanego przeze mnie iteracyjno-przyrostowe procesu inżynierii z opiniami autorów Opinii. Autorzy w ramach podsumowania na str. 83, umieścili tabelę zawierające listę „czynników zwinności” i możliwości ich zastosowania w projektach dla administracji. Wygląda na to, że jest to możliwe, co prawda ja powyżej skupiłem się na opisie metody iteracyjno-przyrostowej, także uznawanej za „zwinną”, ale takich „uznań” mamy wiele w literaturze łącznie z tak zwanym „programowaniem ekstremalnym”.
Sama opinia prawna zawarta w Opinii jest bardzo cenna i wartościowa. Moim zdaniem jednak nie ma potrzeby budowania skomplikowanych mechanizmów prawnych do przeprowadzenia „zwinnego” projektu na bazie PZP. Uważam, że kluczem jest opisane przeze mnie klasyczne inżynierskie podejście (etapy i podział na komponenty – przypadki użycia) i dyscyplina w projekcie. Tu należy zgodzić się, że – za SCRUM – kluczową jest rola Product Ownera, który – nie tylko moim zdaniem – powinien być bezwzględnie rolą po stronie Zamawiającego, oraz rola Kierownika Projektu po stronie Wykonawcy, który powinien utrzymywać bardzo dużą dyscyplinę, mając w umowie bardzo dobrą procedurę komunikacji, zarządzania zmianą i dokumentacją. Największym ryzykiem jest, w moim mniemaniu, założenie wymaganego „zgodnego działania stron” (wiem, ze takie sformułowanie jest w Kodeksie Cywilnym). Każdy kto spotkał się w sądzie ze sporem pomiędzy Zamawiającym oprogramowanie a jego Dostawcą wie, że największym problem jest brak rzetelnej dokumentacji projektowej, w szczególności precyzującej „to co miało powstać”.
(informacja o artykule została wysłana 16.02.2017 na adres Kancelarii biuro@maruta.pl, nie otrzymałem żadnych uwag z Kancelarii)
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Wokół metod zwinnych narasta wiele mitów, szczególnie tych o skuteczności w dużych projektach. Dzisiaj kolejne kilka słów o popularnym narzędziu jakim jest tak zwane „user story” czyli historyjka użytkownika, o ich ewolucji i o tym, że mogą być przydatne i kiedy.
Co prawda, jako źródło informacji wolę dokumenty, ale bywa, że tym źródłem informacji są jednak użytkownicy, bo dotyczy to projektowania np. nowych portali biznesowych. Tu niestety nie ma ani ustaw z wzorami dokumentów ani „dotychczasowego papierowego obiegu dokumentów”. Bardzo podobnie wyglądają start-up’y w obszarze operacyjnym. Podobnie wygląda analiza i projektowanie systemów wspierających obsługę klientów (CRM i podobne). Dlaczego? Bo tej sfery nie regulują ani przepisy ani żadne normy. Nie licząc elementów prawa cywilnego, są całkowicie uznaniowe.
User Story
Historyjki użytkownika, mają swój rodowód w EX (programowanie ekstremalne) i są z reguły definiowane tak:
In software development and product management, a user story is a description consisting of one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function (źr. ang. wiki).
Scott Ambler pisze:
User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. ?1?
Generalnie jest to opis w potocznym języku, ten – z uwagi na niejednoznaczność – jako wymaganie, stwarza problemy. Podejmowane są próby formalizowania tych historyjek. Pisze o tym autor bloga QAgile (podając przykłady, polecam cały artykuł):
W podejściu agile takim jak Scrum wymagania definiujemy na ogól w postaci User Story. Prosta forma, która ma adresować oczekiwania i potrzeby użytkowników często zespołom przysparza dużo problemów w implementacji.?2?
Swego czasu ja także pisałem o efektach stosowania tej metody z zbytnią ufnością w jej skuteczność:
Niedawno po raz kolejny widziałem negatywne skutki tego podejścia, tym razem był to wdrażany i zakończony porażką (projekt przerwano) obieg dokumentów, nie tylko kosztowych, więc postanowiłem do tamtego artykułu dodać coś jeszcze: wymagania zbierano tu z w postaci „user story”.[…]
Tak więc opisowe user story może być wymaganiem biznesowym, testem ale raczej nie specyfikacją tego co ma powstać. Bez analizy pozwalającej wyspecyfikować wymagania dziedzinowe (logikę wewnętrzną) nie mamy szans na sprawne stworzenie oprogramowania wykraczającego poza prosty zestaw kartotek i rejestrów.?3?
User story to opis z perspektywy użytkownika. Najlepszą chyba metaforą będzie tu znana anegdota z opisywaniem słonia:
Każdy z tych okrzyków to odrębne user story.
Wszelkie metody zakładające, że użytkownik wie czego chce i jest najlepszym źródłem „wymagań” bazują na zaufaniu dla tych opisów.
I tu wpadamy w efekt ?kręcenia filmu?. Najczęściej tak zwana analiza wygląda tak, że pracownicy analizowanej firmy, w toku warsztatów lub wywiadów, opowiadają z jakimi to sytuacjami mają do czynienia, co robią, kiedy i jak, opisując konkretne przypadki z jakimi mieli do czynienia i to, jak sobie z nimi poradzili. Do tego dochodzą przypadki, w których sobie słabo poradzili, przypadki tego jak sobie radzą z tym, że czegoś nie rozumieją, a to wszystko jest okraszone sposobami pracy wynikającymi nie raz z niewiedzy, nieznajomości prawa czy wewnętrznych regulacji. Na domiar złego, nie raz można się spotkać z przypadkami, w których opowiadający o swojej pracy wplata elementy pozwalające mu na działania niepożądane takie jak upraszczanie procedur lub wręcz łamanie prawa (np. swego czasu pewien urzędnik na moich oczach w trakcie warsztatów zgłosił jako wymaganie wobec systemu obiegu dokumentów, możliwość podpisania orzeczenia sędziego przeterminowanym podpisem elektronicznym!).?4?
Historyjki użytkownika mają sens, jednak nie jako „kompletny opis wymagań na aplikację” (wczoraj usłyszałem, że w pewnej dużej instytucji zebrano już ok. tysiąca (!) takich historyjek i proces ten nadal trwa). Mają jednak sens jako „sample” do analizy. Przekazywanie takich historyjek bezpośrednio developerowi jest ogromnym ryzykiem. Dlaczego? Historyjka, nawet w sformalizowanej formie, niesie tylko subiektywne „spojrzenie z zewnątrz”, a programista zaczyna domyślać się i gdybać, niejednokrotnie przekraczając dozwolone granice:
…?jako sprzedawca, dostaję od klientów zamówienia, na podstawie których muszę wystawiać faktury VAT?, do tego analityk doda, np. po analizie otrzymanej partii dokumentów, strukturę zamówienia i faktury VAT oraz ?algorytm? wyliczenia podatków. Jeżeli programista zaczyna ?lepiej wiedzieć? od zamawiającego, forsując np. prostszą implementację, to znaczy, że przekroczył swoje kompetencje, sam sobie ? jako developerowi ? robi krzywdę psując to oprogramowanie bo klient i tak prędzej czy później na tych uproszczeniach ?polegnie?.?3?
Bywa bardzo często, że programista bez żadnego oporu przyjmuje historyjkę: „ja jako sprzedawca, chcę umieścić na fakturze towar, którego nie ma jeszcze w magazynie, w celu zaliczenia sprzedaży w danym dniu” … (Komentarz zbędny…)
Czy to znaczy, że należy odejść całkowicie od tego narzędzia? Moim zdaniem nie. Wystarczy uznać , że „user story” to WYŁĄCZNIE opis z perspektywy użytkownika, swoiste „jedno spojrzenie z setek możliwych”.
Swego czasu opisałem taksonomię pojęć stosowanych w analizie wymagań:
Taksonomia wymagań na system (źr. opracowanie własne Jarosław Żeliński)
U szczytu tej hierarchii mamy wymagania biznesowe. Są to w zasadzie owe historyjki użytkownika. To wyrażone językiem zamawiającego, oczekiwania w stosunku do oprogramowania. Rolą analityka jest takie przeanalizowanie i przetworzenie tych opisów, by doprowadzić do powstania sformalizowanego opisu (np. w postaci modeli UML: przypadki użycia, model dziedziny, ograniczenia, inne) czyli do postaci specyfikacji usług aplikacji i logiki (mechanizmu) działania tej aplikacji.
Kolekcjonowanie wymagań biznesowych w postaci np. user story, ma sens jako zbieranie „sampli”, przykładowych sytuacji. Na ich podstawie, w toku analizy, można tworzyć modele i testować te historyjki (stają się scenariuszami testowymi). Tu polecam między innymi blog i książki Scotta Amblera:
In this episode, Scott Ambler helps us to understand the power of using models and how to use models in an agile environment.?5?
Wspominałem nie raz o nim i o jego książkach na tym blogu:
Co prawda książka ma 12 lat i trzeba brać na to lekka poprawkę, jednak jest to wartościowa, nafaszerowana diagramami UML, książka traktująca o tym, że zwinność nie oznacza bałaganu i pospolitego ruszenia. Scott Ambler to kolejny autorytet w inżynierii oprogramowania. I mimo, że nikogo nie ma sensu małpować, na pewno warto się uczyć? ?6?
Ostatnio popularność zdobywa podejście sformalizowane do historyjek użytkownika, bazujące na koncepcji Scott’a Amblera (modelowanie) i Rona Jeffries’a, zwolennika porządkowania, nie tylko treści wywiadów ;). Tu posłużę się ilustracjami z artykułu na stronie Visual Paradigm.
User story is one of the most important tool for agile development. They are often used for identifying the features of a system under developed. User stories are well compatible with the other agile software development techniques and methods, such as scrum and extreme programming. […]
Concept of 3C’s
The 3C’s refer to the three critical aspects of good user stories. The concept was suggested by Ron Jeffries, the co-inventor of the user stories practice. Nowadays, when we talk about user stories, we usually are referring to the kind of user stories that are composed of these three aspects: Card – User stories are written as cards. […] Conversation – Requirements are found and re-fined through a continuous conversations between customers and development team throughout the whole software project. […] Confirmation – or also known as Acceptance criteria of the user story. […]?7?
W dużym skrócie: historyjki dzielimy na jednostkowe elementarne (niepodzielne) opisy w postaci „kart”, zawierających opis tego czego zamawiający oczekuje od aplikacji, zapis uwag (konwersacja) dotyczących kolejnych dyskusji z zamawiającym na temat danej historyjki to historia ustaleń, opis oczekiwanego uzyskanego efektu czynności opisanych w danej historyjce potwierdzenie uzyskania oczekiwanego efektu. Idąc zaś za wskazówkami Amblera, implementację poprzedzamy pracą nad koncepcją implementacji posługując się modelami na dość wysokim poziomie abstrakcji.
Karta historyjki to prosty zapis utrzymany w konwencji „ja jako «aktor», chcę «nazwa czynności» w celu «oczekiwany efekt». Osobiście w projektach dopuszczam bardziej „luźną” formę takiej historyjki, jednak pilnuje co do zasady, by dotyczyła wyłącznie jednego „uzyskanego efektu końcowego”. Każda karta ma unikalne oznaczenie, jest bowiem używana jako jedno zadanie, w backlogu i sprintach (kanban). W dokumentacji (wspomniane narzędzie VP) user story wygląda to tak:
Historyjki mają swój cykl życia i dobrą praktyką jest rejestrowanie wszelkich kolejnych uzgodnień w toku pracy:
Tak zapisujemy „słowotok” zamawiającego na temat jego wizji realizacji danej usługi aplikacyjnej. Analogicznie zapisujemy opis oczekiwanego efektu końcowego:
Do tego momentu mamy „klasyczne” zwinne prowadzenie projektu z jego wadami opisanymi powyżej.
Wymagania powinny być „spójne, kompletne i niesprzeczne”
Jak to osiągnąć? Analityk zaczyna zbierać te historyjki i zaczyna składać z nich kompletny proces biznesowy. Stanowi on weryfikator, czy całość (zestaw takich historyjek) stanowi jakąś spójną, kompletną i niesprzeczną logikę biznesową w skali całej firmy. Zmorą projektów są wymagania odkrywane w toku wdrożenia, dlatego warto poświęcić czas na weryfikację pomysłu na całość systemu i zweryfikować spójność i kompletność tej całości z pomocą utworzenia modelu każdego całego procesu:
Warto modelować proces gdyż wtedy widać, że nie zawsze prawdą jest, że jedna (każda) historyjka jest odrębnym przypadkiem użycia. Przypadki użycia wyprowadza się z elementarnych aktywności jeden do jednego, co z uzasadnieniem opisywałem w artykule Transformacja…. Model procesu biznesowego daje kontekst, pozwala lepiej zrozumieć „sens” całości. Czy powyższy model procesu (notacja BPMN) z naniesionymi historyjkami, nie przypomina Wam wyników badania słonia? Tu słoń został przez analityka odkryty: to proces biznesowy (jego model w notacji BPMN). Przypadkami użycia będą elementarne aktywności w procesie. Więcej na temat zwinnego prowadzenia projektu z użyciem user story można znaleźć w tutorialu Agile handbook.
Na zakończenie…
(źr. Martin Fowler, Analysis Patterns, 1997)
We are called ?analysts? for a reason! We don?t merely hear stories and convert them into ?requirements?. Our integrated value lies in going above and beyond the story and expanding beyond engendering deliverables. We coalesce critical thinking and intellectual curiosity to transform stories into abstracts and to propose the needs as well as what the problem really is.?1?
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Znakomita większość programów zawiera ponad 10 krotnie więcej kodu niż mogła by mieć, bo programiści często implementują warianty zachowań a nie ich mechanizmy (co powoduje, że systemy te są tyleż razy droższe niż mogły by być).
Prawie za każdym razem, gdy mówię (ale nie robię tego jednak zbyt często 😉 ), że stosuję metody naukowe w analizie, spotykam się z zarzutem, że przesadzam. Zapewne nie ma sensu epatowanie w projektach biznesowych akademickim słownictwem, nie ma znaczenia dobór słownictwa w nazwaniu metody pracy, bo znaczenie ma skuteczność.
Twierdzenie naukowe
Poniżej definicja tego czym jest twierdzenie naukowe:
można wobec niego sformułować kryteria pozwalające na eksperymentalne, obserwacyjne lub logiczne ich obalenie (falsyfikowalne według zasad Karla R. Poppera),
istnieją reguły jego odczytania, które ograniczają do skończoności liczbę ich interpretacji (kryterium precyzji Józefa Bocheńskiego),
odnosi się do empirycznie doświadczalnej lub logicznie definiowanej rzeczywistości (tzw. widły Hume?a),
jest elementem zbioru twierdzeń paradygmatu wyjaśniającego rzeczywistość i pozwalającego na przewidywanie jej przyszłych stanów (koncepcja nauki normalnej T. S. Kuhna),
twierdzenie będące najprostszym z możliwych opisów świata (tzw. Brzytwa Ockhama).
Graficznie sam proces odkrycia naukowego można pokazać tak :
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Celowo cytuję tu literaturę z obszaru inżynierii oprogramowania, by pokazać, że nie jestem odosobniony w tym podejściu. Dla porządku podaje także definicje pojęcia model:
model: system założeń, pojęć i zależności między nimi pozwalający opisać (modelować) w przybliżony sposób jakiś aspekt rzeczywistości
Więcej o modelach w nauce: .
Inżynieria oprogramowania
Jeżeli uznamy, że wynik zarówno analizy jak i projektowania, to także modele (przyjmujemy metodę pracy opartą na tworzeniu modeli: MDD/MDA czyli „model driven development”, MDA czyli „model driven architecture”, itp.), to w związku z tym
model, jako wynik analizy, można potraktować jako twierdzenie naukowe opisujące badaną (analizowaną) organizację, jest on zarazem wymaganiem wobec oprogramowania (ma zostać zaimplementowany).
Wyjaśnienie: odniosę się do powyższej definicji twierdzenia naukowego (zgodnie z powyższym pod pojęciem model rozumiemy komplet dokumentacji zawierającej modele, powstałej jako produkt analizy):
kryterium falsyfikacji: dopiero wskazanie w badanej organizacji faktu, którego nie opisuje opracowany model, pozwala uznać model (wynik analizy) za zły,
istnieją reguły jego (modelu) odczytania, czyli do stworzenia modelu użyto sformalizowanych notacji i systemów pojęciowych (np. BPMN, UML, BMM, SBVR itp),
model powstał na bazie, i odnosi się wyłącznie do, zebranych w toku analizy faktów (w szczególności dokumentów, które powstają w toku pracy analizowanej organizacji – dokumenty opisują fakty np. faktura to opis faktu dokonania sprzedaży),
model pozwala na przewidywanie tego co zajdzie w odpowiedzi na określone bodźce (paradygmat procesowy opisujący zachowania i paradygmat obiektowy opisujący struktury), mając model procesów biznesowych można przewidzieć produkt procesu, mając model aplikacji można przewidzieć produkt każdego przypadku użycia,
opracowany model jest najprostszy (minimalny) z możliwych, czyli nie da się już z niego usunąć nic bez spowodowania jego zniszczenia (uczynienia nieprawdziwym).
Tu, dla dopełnienia, warto dodać powszechnie uznawaną w świecie nauki definicję prawdy (A.Tarski): twierdzenie prawdziwe to twierdzenie korespondujące z faktami.
Tak więc mamy to co chcemy czyli kryterium odbioru dokumentacji analitycznej i projektowej: nie jest to liczba stron a „to, że mówi prawdę”.
Z drugiej strony, niestety nie istnieje możliwość wykazania poprawności dokumentacji powstałej w wyniku ankiet, wywiadów czy burzy mózgów spisanej językiem naturalnym … .
Tę „ciężką artylerię”, jak ta tu opisana, wytaczamy głównie dla projektów ryzykownych i kosztownych… 😉 oraz wszędzie tam gdzie ważna jest ochrona know-how.
Dodatek
(dwa dni po publikacji)
Właśnie podesłano mi link do ciekawego tekstu:
One of the most important elements of every Business Analyst?s toolkit is process modeling, which is also significant activity for Business Process Management professionals. For BPM market B? (Źródło: BPMN for Business Analysts ? why, when and how)
Przejrzałem treśc i wszystkie wypowiedzi one „kręcą się” wokół dokumentowania, prezentacji w celu zatwierdzenia lub zgłaszania uwag oraz niektórzy wskazują na możliwość „rysowania zamiast kodowania w celu wykonania”, albo przeoczyłem albo nikt nie zwrócił uwagi na bardzo – mim zdaniem ważny element – tworzenie modelu organizacji czyli tworzenie hipotezy „tak działacie” jako organizacja.
Problem w tym, że chyba większość „użytkowników” tej (BPMN) – i nie tylko – notacji, stosuje indukcyjne metody uwiarygadniania tych modeli, rozumianych raczej jako schematy blokowe. Podejście bazujące na „dowodzie z ilości” (indukcja): model procesów jest dobry bo bardzo dużo osób (osób akceptujących, recenzentów) tak uznało, jest chyba najgorsze.
To błąd logiczny: nie da się wykazać poprawności metodą indukcyjną. Model owszem powinien być jako diagram zrozumiały dla czytelnika, to nie ulega wątpliwości, jednak jego testy powinny polegać na wskazywaniu (szukaniu) ewentualnych faktów typu „a tu mówi nieprawdę”. Innymi słowy model procesu nie jest „dobry” (odzwierciedla prawdziwy mechanizm działania organizacji) dlatego, że wszyscy go zaakceptowali, jest dobry dlatego, że nikt nie znalazł (nie wskazał) jego wady (nie podważono go).
Tak więc analityk, który podchodzi systemowo do analizy powinien tworzyć hipotezy „tak to działa” i nie dowodzić ich poprawności, a czekać na wskazanie wad. Notacje (BPMN, UML, BMM, …) oraz modele tworzone z ich pomocą, są doskonałym narzędziem do dokumentowania tych teorii.
Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2009). Systematic literature reviews in software engineering – A systematic literature review. Information and Software Technology, 51(1), 7 – 15. https://doi.org/10.1016/j.infsof.2008.09.009
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Popper, K. R. (2002). Logika odkrycia naukowego (U. Niklas, Trans.). Fundacja Aletheia.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Od 17-go kwietnia mamy wersje 13.1 pakietu Visual-Paradigm (i pełnej wersji dla analityków i projektantów: ArchiMetric). Twórcy pakietu bardzo silnie współpracują z analitykami w wielu krajach (należę do nich 😉 ) , zbierają sugestie ale też filtrują je. Cieszy mnie to, że w przeciwieństwie do (jak obserwuję) firmy SPARX (producent Enterprise Architekta), nie wychodzą poza standardy. W VP odrzucają wszelkie formy niestandardowych pomysłów (np. aktor „czas” w Enterprise Architect to kuriozalna, niestandardowa konstrukcja) ale za to implementują sprawdzone pomysły na ergonomie pracy oraz zarządzanie spójnością projektu. Jeżeli to tego dodać zdrowe podejście do agile otrzymujemy kolejną odsłonę oprogramowania CASE, które z jednej strony wręcz doskonale wspiera standardy OMG, nie nagina ich, daje swobodę pracy z nimi (SPARX poszedł w masę gotowych wzorców, z którymi się walczy tworząc diagramy i jest wyjątkowo mało intuicyjny).
Ta odsłona zaowocowała jeszcze większą integracją metod zwinnych z formalizmem notacji, mam wrażenie, że ludzie w Visual-Paradigm mają przybitą na ścianie całą biblioteczkę Scott’a Amblera :). Poniżej przykłąd połączenia twardego modelowania procesów w BPMN z User Story, „sztandarowym” narzędziem w metodykach zwinnych. Po co? Ano po to, by panować nas „spójnością, kompletnością i niesprzecznością”. To narzędzie pozwalające połączyć zalety wymuszenia spójności, jaką daje użycia notacji BPMN i analizy systemowej z „kwiecistością” ludzkich produkcji „słowno-muzycznych” 😉 . Robię tak od lat ale teraz narzędzie daje pełne wsparcie tej metodzie pracy.
Adhere User Stories to Any Diagrams User stories can now be written in any diagram, such as BPD. This allows you to relate users? concern and / or requirements in the form of a story card. Presented along with the system designs. In particular, the visual mapping between user stories and BPMN activities. Which will help to identify user stories based on a business process (diagram). Źródło: What’s New in Visual Paradigm 13.1?
Dla purystów (ja też nim jestem): nadal jest to zgodne z notacją BPMN, bo ta dopuszcza definiowanie własnych symboli z ich składnią i użycie ich na diagramach.
Cieszy mnie, że to narzędzie współtworzą praktycy dla praktyków, bez implementowania nieuzasadnionych pseudoteorii i wymuszania na użytkownikach jakichkolwiek „słusznych poglądów”.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.