Nadal obserwuję to, że model relacyjny i "tworzenie bazowych modeli danych na etapie analizy wymagań" (kanoniczny model danych) trzymają się twardo mimo tego, że nie wiele wnoszą do projektu a narzucają (sugerują) kiepską architekturę aplikacji z jedną relacyjna bazą danych. Co ciekawe zaczynanie od bazy danych jest wręcz zaprzeczeniem zwinności (konieczność ukończenia projektu docelowej bazy danych przed rozpoczęciem kodowania czyli klasyka waterfall, w efekcie betonowanie stanu z dnia rozpoczęcia) mimo, że autorki artykułu piszą o sobie że są agile...) Popatrzmy na to co proponują w tym 2017 roku.: Jeśli w…
Dość często spotykam sie z tezami, że użycie przypadków użycia nie wymaga modelowania procesów i odwrotnie, albo że są to "narzędzia" oferujące podobne lub takie same korzyści, np. tak jak tu: So, as you can see we used different techniques and basically the result is the same. It was not really important what techniques were used unless solution design is complete. It?s just a matter of a habit so if you?re more comfortable with use cases then stick to them or if you?re more familiar with process maps then draw…
"Requirements must be based on facts and real-life scenarios." (wymagania muszą być oparte na faktach i realnych scenariuszach). Więc ile warte są wizje w projektach agile albo wydumane w toku warsztatowych burz mózgów litanie życzeń i pomysłów? Nie tylko moim zdaniem: nie są wiele warte i nie powinny być wymaganiami.
"Im większa niejednoznaczność dokumentu wymagań tym większe ryzyko, że projekt będzie miał kłopoty".Powyższe nie stanowi żadnego odkrycia co nie zmienia faktu, że jakość większości dokumentów wymagań (owe 70%) jest słaba, na co wskazują sami ankietowani.Rola Kierownika Projektu to między innymi zarządzanie ryzykiem. Statystyki są nieubłagane, więc brak dobrego analityka i dobrej analizy wymagań spycha projekt w kierunku kłopotów. No to mamy kolejne badanie: Znaczenie i zapotrzebowanie na specjalistów wg. Forrestera: 70% badanych decydentów uważa, że Analityk Biznesowy to kluczowa postać w projekcie. Jednak nie dlatego, że jest ważniejszy od np. kierownika projektu, bo nie jest ważniejszy. Dlatego, że od jakości jego produktu (analiza i specyfikacja wymagań) zależy właśnie ryzyko całego projektu.Co jest wadą większości analiz biznesowych?
To, że są one tak na prawdę uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji, jej potrzeb (bo raczej nie koniecznie jej pracowników!) i celów biznesowych. Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE! Jakie są niesformalizowane, swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE! Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE!Co zrobić? Używać już na etapie analizy biznesowej i projektowania sformalizowanych narzędzi takich jak standardowe notacje i metodyki, wtedy opisy będą JEDNOZNACZNE. Czy to trudne? Tak, w końcu te 70% porażek to nie przypadek...
