tag:blogger.com,1999:blog-5197374494377847819.post5743320314032360572..comments2024-03-22T22:13:46.650+01:00Comments on Holistycznie o inżynierii oprogramowania: UP-DDD in Action: Planowanie jest nieodzowne, Sir!Sławek Sobótkahttp://www.blogger.com/profile/15082577671795313109noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5197374494377847819.post-57585744199596151392008-11-19T21:43:00.000+01:002008-11-19T21:43:00.000+01:00Witam,Mi szczególnie spodobał się fragment dotyczą...Witam,<BR/><BR/>Mi szczególnie spodobał się fragment dotyczący ścisłego wiązania od początku tematów tzw. analitycznych (zrozumieć domene) z technicznymi (zobrazować jak to wykonamy). Z resztą jest to temat DDD więc Sławku liczę na regularny update toich doświadczeń bo będzie można sprawdzić czy działa i jak działa.<BR/><BR/>Co do wymagań i metod partyzanckich to mimo wszytsko z moich doświadczeń z szeregiem, szpalerem czy kupą (== 12 ??) dostawców nie spotkałem się z takim podejściem. Oczywiście jest on o tyle naganny co po prostu śwadczy o tym że firmę założyli ludzie nie rozumiejący czy jest wytwarzanie oprogramowania. <BR/>Maciuch - jak jest aż tak źle to na prawde jest sporo fajnych firm i można spróbować zmiany. <BR/><BR/>Inaczej - chciałbym wyjść od typów realizacji projektów:<BR/><B><BR/>1) wsio fixed<BR/>2) projekt internal<BR/>3) hybryda czyl time & material<BR/></B><BR/>W większości miałem do czynenia z 1 będąc po stronie zamawjającego. W modelu tym zawsze feruje się twardy waterfall czyli analiza - projekt techniczny - dev. W efekcie pierwszego etapu powstaje analiza która później nie jest możliwa do realizacji bo - pewne fukcjonalności są za drogie do realizacji dla wykonawcy (tu wojna co jest a co nie CR), interfejsy do systemów działają bardzo dobrze ale na opak niż myśleli ich dokumentaliści, część w ogóle nie dzała (80% szansy jeśli nikt ich dotychczas nie używał)a wojna z dostawcą supportu trwa w zaparte a planowany termin zakończenia to przyszły rok ;). <BR/>Dostawca z kolei nie ma dostępnego klienta na stałe (klient jest zajęty i płaci by ne zawracać mu głowy szczegółami) a po drugie związany jest fixed price i nie zrobi czegoś nadmiarowo. <BR/>Jedyne wyjście z pułapki jakie na teraz rysuje mi się - to<BR/>1) angażować projektantów od razu 2) namówić klienta do zapłaty za proof of concept dla kluczowych punktów zapalnych.<BR/><BR/>Pozostałe typy projektów to już zawsze inna bajka. 2 daje możliwość ścisłej współpracy analityków i projektantów więc miodek. 3 to hybryda i bywa różnie ale i tak jest lepiej niż w 1.<BR/><BR/>Pozdrawiam<BR/>AlekAleksander Brancewiczhttps://www.blogger.com/profile/15868680475552436307noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-4376038857605408992008-11-19T10:18:00.000+01:002008-11-19T10:18:00.000+01:00Witam,Gratuluje zabawnego opisu chałupniczo garażo...Witam,<BR/><BR/>Gratuluje zabawnego opisu chałupniczo garażowej (aka partyzanckiej) metodyki wytwarzania oprogramowania - czytając śmiałem się przez łzy - eh... skąd ja to znam ;). Powstaje pytanie co my maluczcy programiści możemy poradzić na taki stan rzeczy panujący w bardzo wielu firmach. Rozwiązaniem może być zmiana roboty, ale w kolejnych firmach prawdopodobnie natkniemy się na to samo - wystarczy że nam naściemniają na rozmowach rekrutacyjnych ;) Większość z nas zaciska zęby i wali młotkiem w takiej garażowej organizacji mimo świadomości albo chociażby przeczucia, że można robić inaczej, lepiej.<BR/><BR/>Pozdrawiam<BR/><BR/>MaciekMaciej Zubalahttps://www.blogger.com/profile/14558884067404174520noreply@blogger.com