agile – Page 7 – JZ IT Consulting Ltd

Zwinna analiza czyli polemika

Post author:Jaroslaw Zelinski
Post published:1 September 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Nie jestem wrogiem Agile, jestem zwolennikiem innego autorytetu: Yourdona, który napisał w swojej książce o modelowaniu UML: bez planów można z marszu zbudować z desek np. budę dla psa bo jest mało skomplikowana i ogarnia ją wyobraźnia przeciętnego człowieka, ale dlaczego tak wielu ludzi próbuje tą metodą budować wielkie biurowce...Ciesze się, gdy pojawiają się polemiki z moimi artykułami, to znaczy, ze ktoś to czyta i budzą one emocje. Czytamy na pewnym blogu (który gorąco polecam jako całość): Zacznę od drobnej złośliwości. W maju, jako że sięgnąłem też do starszych wpisów, autor napisał: ?[...] ja już wyrosłem ze społecznych źródeł wiedzy jakim jest Wikipedia i przytoczę definicję z książek mających konkretnego autora [...]?. A dzisiaj czytam, jak autor krytykuje praktyki Agile ? czerpiąc wiedzę na ich temat z tego społecznego źródła wiedzy. Kończąc złośliwość dodam adresując to do autora, że Wiki i Wikipedia to nie to samo i mają się do siebie tak ja klasa do obiektu. (źr. Zwinna analiza ? TouK). Cóż, problem w tym, że Agile jest głównie na społecznych stronach definiowane więc nie miałem wielkiego wyboru: społeczna metodyka to i społeczna wiedza o niej.... (wiem czym jest i wiki i wikipedia, nie sądzę by tu tkwił problem).

Czy wymagania opisują tylko to “co” system ma robić?

Post author:Jaroslaw Zelinski
Post published:21 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Bardzo często tak właśnie definiuje się produkt analizy wymagań: wymagania funkcjonalne opisują to co ma system robić. W dyskusjach (ile mam ich za sobą :)) z programistami przebija się teza, że analityk specyfikuje to "co" system ma robić, a oni już załatwia sprawę tego "jak" ma to robić. W czym problem? W tym, że funkcjonalności to test rozwiązania a nie wymagania! [...] Przypadki użycia stanowią bardzo mierne przybliżenie rzeczywistości. [...] Tak więc dokument wymagań to nie tylko przypadki użycia. Te są raczej testem poprawności rozwiązania, czy model jest poprawny (przypominam, że przypadki użycia, poza ich scenariuszami, zawierają stan początkowy i stan końcowy akcji użytkownika). [...] Programiści, proszę, nie udawajcie, że znacie się na zarządzaniu, marketingu, biznesie, sprzedaży, rynku, produkcji itp. bo to (poza pewnie istniejącymi wyjątkami) nie prawda, a projektowanie na zasadzie "wydaje mi się że rozumiem" to droga do porażki. [...] System ERP można wybrać na bazie projektu na wyższym poziomie abstrakcji. Analizy firmy także polega tu na opracowaniu modeli procesów. Jednak w tym wypadku ich celem jest stworzenie raczej "modelu filozofii działania" firmy a nie projektowanie systemu od zera.

Czego moglibyśmy się nauczyć od naukowców?

Post author:Jaroslaw Zelinski
Post published:19 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

I tu zaczynają się schody. Bo jeżeli rozumiem programistów, że lubią się bawić, to nie rozumiem dlaczego od razu chcą latać na prototypach samolotów, gorzej, nie chcą czekać na projekt i te śmieszne rysunki techniczne. Dlaczego inżynier mechanik chce zajmować się projektowaniem tego jak ma wyglądać i latać samolot skoro jego rola i kompetencje to konstruowanie a nie np. badanie satysfakcji klienta z lotu na wygodnym fotelu... Jak mam sobie wyobrazić tworzenie samolotu w postaci podstawianych na lotnisko pasażerskie kolejnych prototypów? Czy każdy projekt IT to samoloty? Tak! Tam pracują ludzie, płacą za to i cierpi ich biznes jak oprogramowanie nie zadziała jak trzeba! Co mogę po tym powiedzieć? Państwo sami zdecydujcie co wolicie w swoich projektach: 200% narzutu na swobodne podejście dostawców oprogaramowania czy 20% na dobrego analityka projektanta...

IIBA czyli “jak to niektórzy robią w Ameryce”

Post author:Jaroslaw Zelinski
Post published:14 April 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Dlaczego tak często projekty łamią zasady rozsądku i zarządzania ryzykiem? Wczoraj na sali i w kuluarach padły między innymi takie odpowiedzi: dostawcy oprogramowania bardzo często nie potrafią takiej analizy wykonać bo nie mają wymaganych kompetencji, ale potrafią programować i tylko na to się godzą. dostawcy oprogramowania doskonale wiedzą, że istnieje ryzyko że ich produkt nie spełnia wymagań więc bardzo często nie dopuszczają do takich analiz forsując od razu wdrożenie (wręcz tępią w projektach zewnętrznych analityków!). klienci mają stale do czynienia z dostawcami a bardzo rzadko z niezależnymi analitykami i bardzo często przyjmują wiarę w to co mówią dostawcy.

Co wybrać czyli cykl życia projektu tworzenia oprogramowania

Post author:Jaroslaw Zelinski
Post published:22 March 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Zbiegły się dwa fakty: gorąca dyskusja na forum na temat umiejętności programistów i przy okazji ich roli w procesie wytwarzania oprogramowania oraz przesyłka z kolejną nową książką na moja półkę. Ale po kolei. Najpierw fazy cyklu wytwarzania oprogramowania a potem kilka uwag. Zakupiona książka opisuje całość, ja tu skupie się na jej wstępie. Nie będę jej tłumaczył a jedynie opisze idee. Zwrócę także uwagę na pewne aspekty związane z dostarczaniem gotowego oprogramowania, np. systemów typu ERP lub ich komponentów.