Praca grupowa czyli Syndrom Sztokholmski w projekcie

Od wielu lat lat, produktem mojej pracy są dokumenty opisujące w obiektywny sposób działanie organizacji, zawierające rekomendacje zmian do poprawy sytuacji, także wymagania na systemy informacyjne. Po opracowaniu rozwiązania i pomocy w wyborze jego dostawcy, prowadzę nadzór autorski nad realizacją opracowanego rozwiązania. [1] Po latach pracy nasuwa mi się dość ciekawy wniosek z obserwacji: Zamawiający działają na swoją szkodę! Typowy projekt związany z wdrażaniem nowych rozwiązań to realne potrzeby Zamawiającego. Członkowie zespołu Zamawiającego mają nad sobą terminy  i "nieuchronność" kary za niepowodzenie. W efekcie Dostawca szybko staje się "Panem projektu", bo…

Czytaj dalejPraca grupowa czyli Syndrom Sztokholmski w projekcie

TDD – czy same testy to wymagania?

Na niedawno zakończonej konferencji beIT organizowanej na Politechnice Gdańskiej przez Wydział Elektrotechniki, Telekomunikacji i Informatyki, wygłosiłem referat zatytułowany Filozofia czyli Aplikacja jako element biznesowej rzeczywistości (a nie gra komputerowa). Przesłanie tej prezentacji to: Oprogramowanie bardzo często zastępuje konstrukcje rzeczywiste takie jak zegarek, kartoteka, biblioteka, księgi handlowe, programator pralki i wiele innych rzeczy. Dlatego analiza powinna polegać na zrozumieniu i udokumentowaniu mechanizmu działania "tego czegoś" a nie jedynie na spisaniu zewnętrznych oznak tego działania i zarządzanie tym spisem. Referat miał lekkie podłoże filozoficzne :). Ten artykuł nie będzie jednak powtórzeniem referatu (wyżej link…

Czytaj dalejTDD – czy same testy to wymagania?

Architektura… najpierw a nie na końcu

Szperałem w sieci szukając informacji o architekturze i microservisach, a wpadłem na to: ... communication between two different software modules is proportional to the communication between the designers and developers of these modules. Conway?s law exposes the vulnerability in monoliths as they grow in size. Micro-services may not be the best, but better than monoliths for the contemporary web based applications. (Źródło: Micro-Services: A comparison with Monoliths | My Blog) To "prawo" wyjaśnia dlaczego powstają złe interfejsy a nawet zła architektura: z reguły dlatego, że to - architektura - jest lepszym lub…

Czytaj dalejArchitektura… najpierw a nie na końcu

Kim jest product owner?

Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im jest ktoś, jeden, kto zna i rozumie jak działa dana firma, a nie setki stron dokumentacji czy stenogramy z dziesiątków godzin warsztatów z przyszłymi użytkownikami. Do tego firma ta - nabywca systemu ERP - powinna mieć, nie szczegółowo opisane dziesiątki detalicznie opisanych procesów i ich wariantów, procedur czy setki i tysiące nie raz wymagań, a strategię i taktykę, z której wynika…

Czytaj dalejKim jest product owner?

Agile Product Management with Scrum

Cóż, kolejny raz odkrywam, że jestem zwinny :). A tak poważnie, obserwuję stygnięcie ideologii zwinnych metod i przechodzenie od dogmatów do praktyki. Niewątpliwie otoczenie rynkowe zmienia się szybko i metody strukturalne, tak, te z lat 80'tych polegające na wnikliwej i czasochłonnej analizie i budowie całościowego relacyjnego modelu danych dla systemu i projektowaniu listy jego funkcji, to faktycznie "wodospadowe" złe podejście. Tego nikt rozsądny nie neguje. Zwinność jednak, to nie "rezygnacja z pracochłonnej dokumentacji" (często to właśnie słyszę), a uznanie, że oprogramowanie powinno powstawać relatywnie małymi krokami, przyrostowo. I tyle, nie…

Czytaj dalejAgile Product Management with Scrum

Koniec treści

Nie ma więcej stron do załadowania