UPDATE: Dostaję pytania o prezentację z konferencji. Ostrzegam, że jest oszczędna, bo stawiam raczej na gadanie niż na pokazywanie. Komuś, kto nie był na prezentacji, niewiele ona powie.Umieszczam tutaj.
To, w jaki sposób zorganizowaliście darmową konferencję w takim full wypasie, to chyba pozostanie Waszą tajemnicą. Dziękuję!
Żałuję, że nie mogłem się podwoić a potem znów podwoić, aby być na wszystkich prelekcjach. Szczególnie ubolewam, że nie dowiedziałem się o tym dlaczego pozbywać się wzorców i nic o testach, bo odbywały się tym samym czasie co moja prezentacja. Może dla prelegentów powinny być powtórki :) Byłem u Grześka Dudy i Piotra Burdyło - to był wyjątkowo dobrze zainwestowany czas. Zyskałem przede wszystkim inne spojrzenie na kwestie, nad którymi sam pracuję i się zastanawiam.
Jeżdżę sobie trochę po konferencjach i muszę uczciwie przyznać, że na tej doświadczyłem czegoś zupełnie nowego. Było...rodzinnie. Zaraz po wejściu do budynku Tomek Dziurko przywitał mnie jak starego dobrego znajomego, a przecież znamy się tylko z wymiany paru maili. Nie wiem co sprawiło, że pojawiła się ta rodzinna więź. Może tweetowanie, może czujne oko organizatorów gotowych do pomocy w każdej chwili, a może coś innego.
Zazwyczaj znikam z konferencji zaraz po swojej prezentacji, tym razem z powodów rodzinnych również tak było. Lecz tym razem po raz pierwszy było mi na prawdę z tego powodu przykro. Nawet puściłem to na tłyterze. Potem już zupełnie rozbroił mnie Bartek Zdanowski, który myśląc, że jako uczestnik nie miałem zaproszenia na spoinę, zapytał po prostu: "A może chcesz przyjść?". I jak tu się nie wzruszyć? Za wartościowe prezentacje i przede wszystkim za te przeżyte emocje Kapitule Confitura 2012 bardzo dziękuję.
Saturday, June 30, 2012
Tuesday, June 26, 2012
Ludzie książki piszą
Dwa lata temu pewna firma postanowiła wesprzeć swoje procesy za pomocą systemu ERP. Mieli wiele małych systemów, ale marzyło się im kompleksowe rozwiązanie. Tak się złożyło, że dostałem zlecenie zebrania wymagań, a następnie zaprojektowania architektury owego.
Dwa tygodnie później zachodziłem w głowę jak to się mogło stać, że uzbrojony w całą wiedzę z wiązaną z UMLem (i zakupionym na tę okazję EA), architekturą, programowaniem i doświadczeniem związanym z wytwarzaniem oprogramowania, poniosłem katastrofalną Klęskę. Dokładnie tak Klęskę przed duże "K". Czułem podskórnie, że ten projekt się nie uda i po jakimś czasie okazało się, że miałem rację. Lecz co z tego, ze miałem rację, skoro klient był niezadowolony? Pozostał z nierozwiązanym problem. Problem, którego ja nie potrafiłem namierzyć oraz nazwać.
Kilka tygodni później przypadkiem brałem udział w szkoleniu i prowadzący niby przypadkiem powiedział takie zdanie: "Problem jest początkiem rozwiązania". Do końca szkolenia nie mogłem się już skupić na niczym innym niż to, kołaczące mi w głowie zdanie: "problem jest początkiem rozwiązania".
Po powrocie do domu napisałem ten post. Potem obsesyjne zacząłem zastanawiać się nad moim problem związanym ze zbieraniem wymagań do wspomnianego systemu ERP. Potem w trakcie kolejnych rozmów z klientami zacząłem zauważać coraz więcej reguł jakimi rządzą się takie rozmowy. Powoli włączałem moje odkrycia do swoich szkoleń. W końcu postanowiłem napisać książkę.
Dlaczego ta książka warta jest Twojego czasu? Zwróć uwagę, że wszystkie popularne metodyki w inżynierii oprogramowania: począwszy na OOD a na DDD skończywszy mówią o: odwzorowywaniu rzeczywistości, modelowaniu procesów biznesowych, modelowaniu dziedziny, kruszeniu dziedziny, itd. I tylko drobnym druczkiem jest w tych książkach napisane, że zakłada się, iż wiadomo, co trzeba zrobić. A guzik prawda! Nie bez powodu narzekamy na nieprecyzyjne wymagania. Zapewniam Cię, że gdybyś dokładnie wiedział, co należy zrobić, to nie miałbyś najmniejszych kłopotów z zastosowaniem OOD, TDD, BDD, DDD, DDDD i jeszcze więcej "D". Z architekturą i późniejszym utrzymaniem też by nie było kłopotów.
Metody inżynierii oprogramowania zajmują się modelowaniem rzeczywistości. Ta rzeczywistość znajduje się w głowach Twoich klientów. I o odkrywaniu właśnie tej rzeczywistości jest książka Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce?.
Dwa tygodnie później zachodziłem w głowę jak to się mogło stać, że uzbrojony w całą wiedzę z wiązaną z UMLem (i zakupionym na tę okazję EA), architekturą, programowaniem i doświadczeniem związanym z wytwarzaniem oprogramowania, poniosłem katastrofalną Klęskę. Dokładnie tak Klęskę przed duże "K". Czułem podskórnie, że ten projekt się nie uda i po jakimś czasie okazało się, że miałem rację. Lecz co z tego, ze miałem rację, skoro klient był niezadowolony? Pozostał z nierozwiązanym problem. Problem, którego ja nie potrafiłem namierzyć oraz nazwać.
Kilka tygodni później przypadkiem brałem udział w szkoleniu i prowadzący niby przypadkiem powiedział takie zdanie: "Problem jest początkiem rozwiązania". Do końca szkolenia nie mogłem się już skupić na niczym innym niż to, kołaczące mi w głowie zdanie: "problem jest początkiem rozwiązania".
Po powrocie do domu napisałem ten post. Potem obsesyjne zacząłem zastanawiać się nad moim problem związanym ze zbieraniem wymagań do wspomnianego systemu ERP. Potem w trakcie kolejnych rozmów z klientami zacząłem zauważać coraz więcej reguł jakimi rządzą się takie rozmowy. Powoli włączałem moje odkrycia do swoich szkoleń. W końcu postanowiłem napisać książkę.
Dlaczego ta książka warta jest Twojego czasu? Zwróć uwagę, że wszystkie popularne metodyki w inżynierii oprogramowania: począwszy na OOD a na DDD skończywszy mówią o: odwzorowywaniu rzeczywistości, modelowaniu procesów biznesowych, modelowaniu dziedziny, kruszeniu dziedziny, itd. I tylko drobnym druczkiem jest w tych książkach napisane, że zakłada się, iż wiadomo, co trzeba zrobić. A guzik prawda! Nie bez powodu narzekamy na nieprecyzyjne wymagania. Zapewniam Cię, że gdybyś dokładnie wiedział, co należy zrobić, to nie miałbyś najmniejszych kłopotów z zastosowaniem OOD, TDD, BDD, DDD, DDDD i jeszcze więcej "D". Z architekturą i późniejszym utrzymaniem też by nie było kłopotów.
Metody inżynierii oprogramowania zajmują się modelowaniem rzeczywistości. Ta rzeczywistość znajduje się w głowach Twoich klientów. I o odkrywaniu właśnie tej rzeczywistości jest książka Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce?.
Subscribe to:
Posts (Atom)