Ten post ma 11 komentarzy

1. 

   Matthias 24 maja 2011

   “Szkoda, że nie raz na cudzej skórze”… hm,… A na czyjej skórze chciałbyś się uczyć? Na swojej? Gdyby tak podejść do sprawy to wszyscy pracowaliby w jednoosobowych projektach open-source, które nikomu nie służą a jak wiadomo tak nie jest. Poza tym dochodzi do tego wszystkiego wstrętna i pokrętna polityka, która niejednokrotnie rozwala cały proces nieważne czy agile czy waterfall czy cos innego jeszcze pomiędzy.

   1. 

      Jarek Żeliński 24 maja 2011

      Ja się uczę na swojej skórze i na swój koszt bo to, uczciwe. Ok. 50% mojego czasu w miesiącu poświęcam, poza papierami firmowymi, na “projektowanie na sucho” i pisanie doktoratu. Znam wielu programistów, którzy robią podobnie, zresztą projekty open-source właśnie taki mają cel: uczyć się bez szkód dla innych: uczciwie. Współpracuje z programistami, którym było by wstyd obiecać klientowi coś czego jeszcze nie robili. Co do polityki w tej czy inne firmie to jest stare korporacyjne powiedzenie: “nie akceptujesz i wychodzisz albo akceptujesz i zostajesz”.

2. 

   Paweł Lipiński 1 czerwca 2011

   Po przeczytaniu tego wpisu zastanawiam się, czy nie powinno się jakoś karać rozprzestrzeniania FUDu…
   To co piszesz jest grubo nieprawdziwe, albo bazuje na niezrozumieniu paru spraw. Po kolei:
   1) Zdajesz się nie rozumieć obiektowości i związanego z nią procesu programistycznego. Nie winię Cię – zdaje się, że po prostu się tym na codzień nie zajmujesz, dziwię się tylko, że poruszasz ten temat. Co więcej Twoje tłumaczenia są delikatnie manipulacyjne (np. “Anaysis is done before…” nie oznacza “Analiza powinna być wykonana…”) Co więcej wzięcie pierwszego akapitu z wikipedii wyrywa tekst z kontekstu. Np. nie wziąłeś już pod uwagę następującego (kluczowego dla zwinnych metodyk) zdania (z artykułu o projektowaniu): “Both analysis and design can be performed incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.” Hm – to zdanie zaprzecza Twojemu diagramowi…
   Dobrze, że nawiązałeś do DDD, bo to podejście bardzo silnie zaprzecza fazowemu podejściu do tworzenia oprogramowania. Z resztą Eric Evans (autor DDD) pochodzi bezpośrednio ze zwinnych środowisk (konkretnie XP). Zachęcam do przeczytania jego książki, a zobaczysz jak wymagania i model koncepcyjny wyłaniają się W TRAKCIE programowania.
   2. Nawiązanie do zwinnych metodyk wskazuje niestety na pewne niedoczytanie źródeł. Nigdzie nie jest napisane, że 80% projektów się nie udaje ze względu na brak analizy (albo ja nie znam takich opracowań). Jest za to napisane, że zwinne metodyki zmniejszają ryzyko (http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS)
   3. Teraz konkrety dot. agile.
   3a. W zwinnych metodykach nie jest tak, że nie ma analizy. Jest i to zwykle dużo dokładniejsza niż w klasycznym fazowym podejściu, bo dzieje się CIĄGLE, przez cały czas trwania projektu. I oczywiście, że jest ona w większości przed programowaniem danej funkcjonalności (spotkanie planningowe, spotkanie backlog grooming, a nawet ad-hoc rozmowy przy kawie przenoszące się na whiteboard), a tylko w części w trakcie programowania (dopytujemy w trakcie programowania – wykrywamy dodatkowe przypadki, po pokazaniu klientowi odpowiedniego kawałka UI, itp).
   3b. W zwinnych metodykach nie jest tak, że nie ma projektowania. Jest i to zwykle dużo dokładniejsze niż w klasycznym fazowym podejściu, bo dzieje się CIĄGLE, przez cały czas trwania projektu. Każda nowa funkcjonalność jest opracowywana zaraz przed rozpoczęciem programowania pod względem jej umieszczenia w systemie (architektura) oraz jej wewn. projektu (design). Oczywiście szczegóły w rodzaju wzorców projektowych powstają/wyłaniają się w trakcie developmentu, ale dla trudniejszych przypadków duża część pracy odbywa się na papierze i whiteboardzie. Tak więc projektujemy zarówno przed developmentem jak i w trakcie. Tyle, że znów: iteracyjnie/inkrementalnie i per-feature.
   4. Stawianie pozycji analityka jako przeciwieństwo agile jest nie fair. Analityk może (a nawet musi) mieć swoje miejsce w zwinnie prowadzonym projekcie (i nazywa się np. product owner albo customer w zależności od metodyki), tyle że lepiej żeby nie był analitykiem z zawodu, tylko ekspertem danego biznesu. Dlatego w naszych projektach analitykiem jest np. specjalista od roamingu czy logistyk. I pracuje iteracyjnie dostarczając i pogłębiając nam wymagania. I nie nazywamy go analityk, ale to pewnie tylko kwestia nazewnictwa.
   Podsumowując w zwinnych metodykach nie chodzi o to, żeby “rzetelnie wykonać analizę i projekt zanim rozpoczniemy kodowanie” tylko maksymalizować prawdopodobieństwo sukcesu przez zbliżenie i maksymalizację efektywnej komunikacji między biznesem, architekturą i developmentem, by maksymalizować przynoszoną wartość.

   Polecam artykuł, który jakiś czas temu napisałem:

   pozdrawiam
   Paweł

   1. 

      Jarek Żeliński 1 czerwca 2011

      Na początek zaznaczę, że każdy ma prawo do swojego zdania, i Ty i ja.

      Ad.1. Obiektowość to nie tylko obiektowy kompilator ale także analiza i modelowanie, pragnę przypomnieć, że języki programowania obiektowe powstały w odpowiedzi na obiektowy paradygmat analizy i projektowania a nie odwrotnie, są implementacją obiektowości.

      Analiza i projektowanie (owe wspomniane “analysis and design”) obiektowe nie mają nic wspólnego z pisaniem kodu i faktycznie jest iteracyjne, kod ten jest wtórny do projektu: to implementacja wyników projektowania obiektowego.

      DDD to styl projektowania a nie programowania, to drugie to jest implementacja projektu (powtarzam się). (DDD Evansa jest na mojej półce, nie ma tam nic – nie znalazłem – o kodowaniu bez poprzedzającego go, iteracyjnego, projektowania).

      2. W kwestii zastosowań zwinnych metodyk polecam http://it-consulting.pl/autoinstalator/wordpress/index.php/2011/03/22/co-wybrac-czyli-cykl-zycia-projektu-tworzenia-oprogramowania/, podsumowanie wielu źródeł o programowaniu i metodach.

      ad.3. Nie piszę o tym, że w zwinnych metodykach nie ma analizy a o tym, że jest ona “rozpoznaniem bojem” a to właśnie krytykuję…

      ad.4.Chodzi mi o to, że “rozpoznanie bojem” na papierze (analiza i modele) jest skuteczniejsze i tańsza niż od razu z pomocą zespołu koderów i kodowania. Fazowość postrzegam jako oddzielenie szukania rozwiązania od jego implementacji.

      Dlaczego o tym w ogóle piszę? Bo porównanie ofert wygląda tak (jeden z wielu moich projektów):
      Wariant 1.: Zwinne metodyki itp.: oferty na bazie opisu przyszłego użytkownika oscylują w granicach 450-700 tys.
      wariant 2.: analiza i projektowanie, potem implementacja: oferty na bazie wcześniej projektu UML mają już wartość 170-200 tys., poprzedzający koszt analizy i projektu w tym projekcie, ok. 30 tys. Każdy potrafi liczyć. Projekt zamknięty, wykonany w terminie i w budżecie: implementacja kwartał, oddana w wersji pierwszej do użytku. łączny koszt to 200 tys. zamiast 450tys. (?700?). Tak to wygląda. To moje doświadczenia.

      Dla mnie obiektywnym miernikiem są zakończone i rozliczone projekty oraz pierwotne oferty jako porównanie.

      Może do zobaczenia na Confiturze 11 Czerwca :), nie ma co się emocjonować.

      Jak mam rozumieć “zabronić” w sensie jakichkolwiek wypowiedzi? Cenzura niewygodnych tez? Polecam także to:

      oraz to:

      http://msdn.microsoft.com/en-us/library/dd409423(v=VS.100).aspx

3. 

   Paweł Lipiński 1 czerwca 2011

   To zacznę od tego, że z tym zakazywaniem to oczywiście żart. Natomiast uważam (po przeczytaniu paru Twoich wpisów tu i na GL), że porównujesz to co znasz (co ja nazywam teoriami i praktykami z lat 80-90tych) z tym o czym chyba tylko czytałeś (agile, DDD, itp). Przykłady? Np. we wpisie o metodykach piszesz, że Scrum jest ściśle programistyczny, co wyraźnie wskazuje, że mylisz go z XP. Scrum to framework niezależny (w założeniach) od typu projektu – czy to informatyczny, logistyczny, administracyjny, czy jakikolwiek inny.
   Nie próbuję Ci odebrać zdania, tylko zachęcam do poznania w praktyce (najlepiej dobrej…) tego o czym piszesz.

   A teraz komentarz do komentarza do komentarza:
   Ad Ad 1. Obecne projektowanie/programowanie obiektowe wcale nie ma wiele wspólnego z analizą obiektową. Szczególnie w projektach biznesowych, gdzie 90% kodu to infrastruktura, ujarzmienie technologii i GUI a nie logika biznesowa. Co więcej narzędzia do analizy obiektowej (use case’y, przepływy, sekwencje itp) rzadko dobrze się mapują na programowanie obiektowe, za to świetnie na proceduralne, stąd trudno o dobrze obiektowy kod w takich projektach (no dobra – nie koniecznie taki jest główny powód, ale to jeden z nich).
   A co do DDD, to na raz i masz rację i nie. Masz na płaszczyźnie lingwistycznej – w końcu Design to nie programowanie. Nie masz za to w warstwie znaczeniowej, bo pewnie nie wiesz, że Evans był związany z XP bardzo mocno i dla niego projektowanie i programowanie (jak dla wszystkich XPowców) to nierozdzielne aktywności. Dlatego w książce pisze o tym, że ma ze sobą eksperta, z którym gadając pisze kod. Pisze go najchętniej w DSLu, żeby ekspert zrozumiał i mógł ew. zgłosić poprawki. Tak więc na raz projektuje (zgłębiając swój model koncepcyjny i domenę) i programuje, bo powstaje z tego “rich domain model” używany potem w aplikacji. Powstaje/prezycuje się też ubiquitous language, co jest już zupełnie analityczną rzeczą.
   Ad Ad 2. Przejrzałem wpis i faktycznie ciekawy, choć nie bez uwag 😉 Model wodospadowy w takiej formie jak go narysowałeś nie istnieje i nie istniał nigdy (Winston Royce miał na myśli coś innego, co fajnie pokazane jest tu: http://www.youtube.com/watch?v=X1c2–sP3o0). Scrum to (jak już pisałem) niezależna od kodowania metodyka (a nie metodologia, która po Polsku jest nauką o metodykach), w której często stosuje się praktyki XP. Dlatego nazywana jest czasem XP nie tylko dla orłów. Do tego zwinne metodyki stosuje się nie tylko w małych projektach i to ze znaczym sukcesem. Np. w mojej firmie nasz główny projekt trwa już ponad 2 lata, a mamy zagwarantowane jeszcze do końca roku. Zespół jest paronastoosobowy. W samej javie jest teraz coś pod 200k linii kodu. I uwierz mi, to co wyanalizowali na początku ma się nijak do tego, czego chcą teraz. Bo nie tylko zmieniły się ich oczekiwania, ich klientów, technologie, to jeszcze wiele rzeczy okazało się dopiero jak dało się w nie kliknąć.
   Ale zgadzam się w 100% z tym, że XP (i w ogóle agile) wymaga b. dużej odpowiedzialności i świadomości zespołu. Stąd rola coach’a/scrum mastera, który ma dbać o proces i zespół.
   Rozróżnienie podejścia z prototypami, prototypami odrzucanymi od innych metodyk jest wg mnie błędem, bo to ortogonalna do metodyki technika. Stosuje się je i w wodospadach i w agile’u. Z resztą w agile’u bardzo często (bo idealnie wpasowuje się w iteracyjność i częsty kontakt z klientem), więc wpisywanie dla nich innych wartości w tabelce porównawczej jest błędem. Tak – wg mnie oczywiście 😉
   Ad Ad 3. No właśnie problem jest taki, że nie bardzo się da rozpoznać bez boju. Tzn czasem się da więcej, czasem mniej, ale nigdy 100%. Zawsze coś rozpoznasz dopiero w boju – i to w cale nie tak mało. Dlatego nie jestem za atakowaniem z kodem dziedziny od pierwszego dnia, za to spędzanie 25% czasu projektu na analizie też nie jest wg mnie dobrym rozwiązaniem. Komentarz do bloga to za krótka forma, żeby pisać dlaczego (głównie psychologia się tu kłania – drogi na skróty, zmiana wymagań, liczba ogniw w łańcuchu komunikacji, itp).
   Ad Ad 4. Każdy programista Ci powie, że modele przygotowane w UMLu można w większości o kant D rozbić. Do tego ich tworzenie jest niesamowicie kosztowne, a utrzymanie aktualnych jeszcze bardziej. Zwiększają więc one tylko koszty wcale nie zmniejszając ryzyka. Pracowałem jako architekt przez parę lat, przy naprawdę dużych systemach i uwierz – kod ma się nijak do tego co architekci / designerzy UMLowi produkują. Z resztą nie może być inaczej – żaden mniej złożony system nie może kontrolować bardziej złożonego. A architektura czy analiza jest z natury rzeczy mniej złożona od programowania. Operuje w końcu na abstrakcjach, uogólnieniach i założeniach a nie na faktach.
   Ale i tak zgodnie z Twoimi przemyśleniami uważam, że wielu problemów programistycznych można by uniknąć gdyby były lepiej przemyślane przed zgłoszeniem zespołowi (a więc zanalizowane). Dlatego nie uciekam od analizy – nawet szczegółowej – ale wybiórczej, tzn. realizowanej w odpowiednich szczegółach tam gdzie ma to zastosowanie.

   Porównanie ofert o którym piszesz nie dowodzi NICZEGO W OGÓLE. Kwoty w ofertach zwykle wystawia się na podstawie zgrubnych, niepełnych, często sprzecznych wymagań, w oparciu o czynniki ryzyka, grube oszacowania i ssanie z palca. Do tego dochodzi polityka i kolesiostwo. W Twoim przypadku goście agile’owi pewnie nie chcieli ryzykować, więc walnęli “z góry” – z resztą chętnie bym się dowiedział jak liczyli. Goście od UML’a (a Ci agile’owcy nie mieli tego UML’a?) za to pewnie chcieli po prostu zrobić projekt, licząc, że jeśli coś się pojawi ryzykownego to się chwyci klienta na CRy. A może nie – a może po prostu oni do tego usiedli i policzyli, a agile’owcy wyssali z palca licząc na brak konkurencji? Kto wie…
   Tak czy siak, mogę Ci powiedzieć, że my liczymy na podst. zapytania ofertowego tak:
   1. robimy z wymagań coś a’la user story
   2. porównujemy do aktualnie robionego projektu (rozmiary story)
   3. szacujemy względem aktualnego
   4. przeliczamy względem aktualnego (prędkości zespołu)
   Więc staramy się nie wysysać z palca, tylko bazować na statystykach. Do tego nigdy nie robi tego 1na osoba, tylko zawsze przynajmniej 2-3, żeby dyskutowały w trakcie wyceniania.

   Do confitury!

   1. 

      Jarek Żeliński 2 czerwca 2011

      “Obecne projektowanie/programowanie obiektowe wcale nie ma wiele wspólnego z analizą obiektową. Szczególnie w projektach biznesowych, gdzie 90% kodu to infrastruktura, ujarzmienie technologii i GUI a nie logika biznesowa”

      Zgadzam się, że 90% to infrastruktura i nie raz to potwierdzałem, jednak w 100% tam gdzie byłem świadkiem kłopotów z odbiorem oprogramowania problem nie tkwił w infrastrukturze a w regułach biznesowych, to że wg. Ciebie są one nie ważne potwierdza tylko ten problem… Otóż to co system ma robić dla użytkownika to w 100% analiza i projektowanie, tu obiektowe.

      Jeżeli uważasz, że “problem jest taki, że nie bardzo się da rozpoznać bez boju.” to Twoje zdanie i masz prawo je mieć. Po raz kolejny przytoczę: “to że nie widziałeś nigdy czarnego łabędzie nie stanowi żanego dowodu na jego nieistnienie”.

      “Każdy programista Ci powie, że modele przygotowane w UMLu można w większości o kant D rozbić.”, uścislijmy: nie każdy i być może te które widziałes lub te których nie potrafiłeś przeczytać, nie wiem, pokaż takie przykłady to będę miał swoje zdanie… jak na razie ci programiści z którymi ja wspólpracuję w 100% korzystają z modeli UML i to dzięki ich umiejętnościom miewam proporcje 200 tys. vs. 700tys. u konkurentów.

      “do tego ich tworzenie jest niesamowicie kosztowne”, wybacz ale to już jest bełkot…ja też takie tworze je wiem ile kosztują.

      “kod ma się nijak do tego co architekci / designerzy UMLowi produkują”, współczuje kompetencja zespołu, kluczową miara zespołu analityków i projektantów jest to jak się ma produkt końcowy do projektu. Jeżeli nijak się nie ma to…

      “porównanie ofert o którym piszesz nie dowodzi NICZEGO W OGÓLE.”, dowodzi prostej rzeczy: istotnie się różnią.

      “my liczymy na podst. zapytania ofertowego”, które jest czym? Projektem? Opisem? Życzeniem? Jeżeli ktoś potrafi złożyć ofertę nie wiedząc co ma zrobić (a co najwyżej, do czego to posłuży) to ja podziwiam, w szczególności narzut na tę niewiedzę.

      Do konfitury… mamy na prawdę bardzo odmienne doświadczenia i jak to mówią, rynek to oceni nie my, kończę ten spór…

4. 

   Mateusz Kurleto 2 czerwca 2011

   Najpierw się przyczepię:
   “Mając obiektowy model organizacji i cel projektu (koniecznie) tworzymy projekt przyszłego oprogramowania. Tu mała uwaga: oprogramowanie to dwa aspekty: jego funkcjonalność oraz techniczne parametry takie jak bezpieczeństwo, wydajność i dostępność. Funkcjonalność wynika wprost z produktu analizy obiektowej, parametry techniczne to poza biznesowe elementy, których projektantami są inżynierowie i programiści.”
   1) techniczne parametry takie jak(…) – to są pozafunkcjonalne wymagania zwane także ograniczeniami a nie żadne techniczne aspekty, wymaganie na maksymalny czas odpowiedzi, poziomy pewności algorytmów decyzyjnych, czy ilość przetwarzanych danych, albo informacje o planowanym obciążeniu – to też wymagania pozafunkcjonalne i nie mają żadnych technicznych aspektów:P
   2) te wymagania (pozafunkcjonalne) wcale nie wynikają z pracy inżynierów i programistów, one jak najbardziej wynikają z analizy biznesowej; to biznes musi wyznaczyć pewne granice w ramach których oprogramowanie ma być realizowane – wymagania na wydajność, pojemność, etc. wynikają wprost z analizy biznesowej przykład wymagania biznesu “system ma być bezpieczny”-bzdura (co to znaczy bezpieczny?) “system ma korzystać z protokołu SSL”-mniejsza bzdura(jakiego? i czemu właśnie tego?) “system ma przesyłąć dane szyfrowanym łączem, uniemożliwiającym podsłuchanie i odszyfrowanie przesyłanych komunikatów w czasie <1 dnia przez komputer osobisty"-dobre wymaganie, które projektant zamieni na – kożystamy z takich to a takich sposobów szyfrowania łącza, takich to a takich funkcji hashujących hasła, stosujemy min. 1024 bitowe klucze etc.

   A co do Waszej dyskusji:
   1) Jarku, daj sobie spokój z tym notorycznym jeżdżeniu po Agile jako idei. Już tak wiele razy przyznałeś mi rację, gdy tłumaczyłem, że to dobre narzędzie w obszarze jego użytkowania, a dobre praktyki Agile wcale nie pomijają analizy i projektowania. Nie spłodzę tak zgrabnego tekstu (a przynajmniej nie sam) na ten temat, ale naprawdę Twoja antypatia wynika z efektu krzywego zwierciadła.
   Czytasz o Agile i obserwujesz projekty, mieniące się Agile – choć tak naprawdę z dobrymi praktykami nie mają one nic wspólnego. Ludzie programują na pałę i im się wydaje, że jak szacowali grając w poker'a to są Agile. Nie są, choć tak mówią – to nie jest Agile. Potępiaj kiepskie wykonanie, a nie naprawdę solidne narzędzie projektowe:P Jak mnie sprowokujesz to w końcu zrobimy razem projekt Agile, żeby Ci udowodnić, że to wielkie dobro, jak się umie tego używać.

   1. 

      Jarek Żeliński 2 czerwca 2011

      Wydaje mi się, że wiele nieporozumień, w takich ja ta wymiana poglądów, jest wynikiem swobody używania pojęć “ogólnie postrzeganych jako znane”. Prawdę mówiąc, nie mam nic przeciwko jakimkolwiek programistom, jednak trudno mi zaakceptować pewne praktyki. Wydaje mi się, że wystarczy np. zrezygnować ze słowa Agile a zacząć pisać o konkretnym przypadku i konkretnej pracy a problem zniknie. Ja kilka lat temu używałem pojęcia “zwinna analiza i projektowanie” na zmianę z Agile Analysis, mając na myśli po prostu adaptacyjny sposób dobierania zakresu projektu i sposobu jego prowadzenia. Po kilku “zarzutach”, teraz uważam słusznych, zrezygnowałem. Dlaczego? Bo to co robiłem nie miało nic wspólnego z owym manifestem agile. Osobiście, jako zwolennik podnoszenia jakości komunikacji – precyzowania używanych pojęć – uważam, że jak długo słowo Agile ma tyle definicji ilu jest ludzi go używających, tak długo jego używanie będzie się wiązało z takimi nieporozumieniami. Tak więc nie jeżdżę po Agile a po tym, że to słowo nic nie znaczy (poza tłumaczeniem: zwinność).

      Ad.1. Widzisz tu mamy kolejne nieporozumienie ;). Krąży wiele definicji pojęć “wymagania funkcjonalne i poza funkcjonalne”, nie raz pojawiają się także inne. Dla mnie aspektem technicznym jest to, że “spodziewamy się 2 milionów dokumentów w repozytorium”, bo z tym musi sobie poradzić dostawca “technologii”, także z algorytmami wyszukiwania. Wymaganiem funkcjonalnym będzie to, jakie metadane będą opisywały te dokumenty, poza funkcjonalnym to, że czas wyszukiwania dokumentu nie powinien przekroczyć 5 minut. Tym ostatnim zajmą się już (tak sądzę) inżynierowie a nie analityk (lub stwierdzą, że nie da sie tego osiągnąć).

      Ad.2. Masz rację, wymagania poza-funckjonalne musi ktoś określić, biznes czy analityk biznesowy. Twój przykład z SSL jest bardzo dobry, ja także uważam, że “poziom bezpieczeństwa” to wymaganie (ograniczenie) a ów SSL to implementacja. Pierwsze pisze analityk drugie “wymyśla” inżynier odpowiedzialny na projekt implementacji. Jak widać, bałagan pojęciowy jest i mamy nieporozumienia. Co do stwierdzenia “system ma być bezpieczny” ono samo z siebie jest niemierzalne, racja. Wypadało by napisać “jak bardzo bezpieczny” i określić miarę. Jednak miejmy świadomość, że np. ustawodawca posłużył się pojęciem “bezpieczny podpis elektroniczny”. Co to znaczy? Nic, chyba że uznamy, że “bezpieczny podpis elektroniczny” to taki, przy którym zastosowano konkretną, opisaną w innych dokumentach ustawodawcy technologię. Tak więc czasami “wypada” posłużyć się “ogólnie przyjęta wiedzą” a dla precyzji wpisać ów SSL jako “przykład pojmowania” tego poziomu bezpieczeństwa.

      Dlatego ja, by uniknąć nieporozumień, nie używam słów “Agile”, “zwinne metody” itp. Po protu należy napisać co i jak się robi (zrobi). Niestety wielu dostawców “systemów” nie potrafi (nie chce?) z góry napisać co i jak zrobią i z tym “walczę” a nie z dobrymi praktykami, które nie raz sam stosuję. Ilu programistów (firm) tworzy dokument “hermetyzacja”, który Ty stosujesz? Ilu programistów (firm) potrafi z góry zadeklarować do dostarczą? Moje “ataki” dotyczą bałaganu pojęciowego w ofertach i protokołach przekazania. Zbyt wiele programów, za które wystawiono fakturę a które do niczego nie służyły, widziałem. To nie ja wymyśliłem, że firma programistyczna ma mieć dobrego prawnika a nie dobrego programistę. Mam także świadomość, że wiele firm programistycznych (nie wszystkie) atakuje mnie (i nie tylko mnie) bo przy zbyt dobrze (co by to nie miało znaczyć) określonych wymaganiach, ich projekty są możliwe do rozliczenia a tego wielu z nich nie lubi.

      Na koniec: jak ktoś pisze, że planowanie i projektowanie należy wytępić, będzie moim “wrogiem”. Czym jest opracowanie wymagań i zaprojektowanie logiki systemu jak nie planowaniem i projektowaniem? Przytaczanie przykładów wyjątkowo złej jakości dokumentów analityków (a prawda jest, że produkują takie nawet zacne giełdowe spółki informatyczne!), to nie argument by z analiz (analityków) zrezygnować a argument za tym by pilnować lepiej ich jakości. Idąc tym tropem, po tym co nie raz widziałem, powinienem głosić tezę by zarzucić w ogóle informatykę i zwolnić wszystkich programistów – to nie ja wymyśliłem pojęcie “kryzys oprogramowania”… ale to głupie więc tak nie powiem.

5. 

   Piotr Tokarski 28 czerwca 2011

   1. Bądźmy precyzyjni w manifeście Agile nie przypadkowo użyto słowa ponad (eng. over) a nie zamiast (eng. instead).
   2. Manifest agile jest napisany z punktu widzenia dostawcy oprogramowania

   Jako programista/projektant ceniam to tak że pisanie na podstawie kiepskiego projektu jest nieprzyjemne , różnica tylko taka że jeśli projekt jest własny zaczyna przeszkadzać dopiero po pewnym czasie .

   1. 

      Jarek Żeliński 28 czerwca 2011

      Witam
      1. czyli ograniczenie czasu (a podobno zawsze go za mało w projektach) zaowocuje rezygnacją z projektowania/dokumentowania, moim zdaniem uczciwsze jest powiedzenie klientowi, że na coś jest po protu za mało czasu…
      2. zgadzam się w 100%, ale czy to usprawiedliwia dostawcę?
      Prawdą jest, że pisanie czegokolwiek na bazie kiepskiego projektu jest frustrujące, dlatego nie raz słyszę narzekania (słuszne) także na analityków-projektantów…;)

6. 

   Jarosław Żeliński 7 lutego 2019

   Dzisiaj jest 7 luty 2019, nic się nie zmieniło… kilka drobnych poprawek w artykule… “Pan Lipiński” (patrz powyższa dyskusja) nadal dominuje u developerów….

Możliwość dodawania komentarzy nie jest dostępna.