Wymagania niefunkcjonalne (ang. Non-Functional Requirements - NFR) są to wszystkie wymagania opisujące ograniczenia systemu lub wymogi jakie produkt musi spełniać, aby sprostał określonej klasyfikacji. W szczególności to tych aspektów zaliczamy możliwość śledzenia wymagań funkcjonalnych przez cykl życia projektu do kodu źródłowego (ang. traceability), dostępność (ang. availability) czy jakość interfejsu użytkownika (ang. usability).
Z punktu widzenia sukcesu projektu są to zwykle elementy projektu nie mniej ważne jak sama dostarczana funkcjonalność. Czym będzie system bankowy, który nie obsłuży 100 klientów na raz, albo edytor tekstu z kompletnie nieprzemyślanym interfejsem użytkownika.
W metodykach lekkich skupienie jest na iteracyjnym dostarczaniu funkcjonalności. Emfaza położona jest na to jak klientowi dostarczyć kawałki funkcjonalne coraz lepiej dopasowane do jego rzeczywistych potrzeb. Rodzi to naturalne pytanie co z elementami niefunkcjonalnymi? Pytanie to nie jest bezzasadne, bo parę razy udało mi się o nich zapomnieć, na szczęście zawsze ktoś życzliwy z boku odpowiednio wcześnie zadał parę mądrych pytań i uratował sytuację.
Jedną z rad jakie się spotyka to próba przekształcenia wymagań niefunkcjonalnych w wymagania funkcjonalne. Pytanie więc czy rozwiązuje to wszystkie problemy i pozwala kompleksowo podejść do problemu wymagań niefunkcjonalnych, moim zdaniem nie. Jest to mina przez którą można doznać znacznych opóźnień w projekcie, a czasem i poważnych problemów architektonicznych.
Pytania jakie stawiam, by zbadać naturę tej miny to:
Jakie są mechanizmy w metodykach lekkich zapewniające tracebility?
O ile śledzenie ścieżek od wymagania do kodu źródłowego jest wpisane wręcz w takie metodyki jak RUP, to XP czy Scrum nie zawiera jawnie żadnych elementów, które pozwalałyby na to. Wręcz przeciwnie, inicjalna dokumentacja jest z definicji tylko na początek i powinna być wyrzucona jak tylko przejdzie przez iterację i zastąpiona testami akceptacyjnymi oraz jednostkowymi, gdzie zapisane są szczegóły ustaleń funkcjonalnych, które następują w trakcie iteracji dzieki aktywnej współpracy klienta (lub jego proxy).
Dla ścisłości dodam, że Kent Beck w eXtreme Programming Explained 2nd Edition na samym końcu wspomina krótko o tym problemie, ale proponowane rozwiązanie sprawia wrażenie dopisanego do całości na kolanie w parku przed biurem wydawcy w przeddzień publikacji. Wniosek raczej taki, że radzić sobie trzeba z tym jak kto umie. Póki co na szczęście nie spotkałem się z takim wymaganiem w swoich projektach.
W jaki sposób zautomatyzować testy jakości interfejsów użytkownika (usability)
O ile można napisać kartę wymagań o treści "graficzny interfejs użytkownika jest intuicyjny i przyjemny" o tyle kata karta nie spełnia podstawowych wymagań jakie stawiamy kartom. Nie jest automatycznie weryfikowalna. A przynajmniej takie metody nie są mi znane. Zrzucenie tego na testy manualne w obliczu tygodniowych iteracji (czyli zmian w interfejsach GUI) podczas wielomiesięcznego projektu raczej graniczy z obłędem. Nie twierdzę, że automatyzacja jest jedynym wyjściem, bo moim celem nie jest sama automatyzacja. Patrząc zaś na cel jaki dzięki automatyzacji osiągam dostrzegam inne rozwiązania takie jak segmentacja obszarów funkcjonalnych i uszeregowanie dewelopmentu zgodnie z nimi, to pozwoli już ograniczyć zakres manualnych cykli testowych. Wyprzedzająca analiza i podstępujący projekt graficzny wyprzedzający o kilka iteracji dewelopment. I inne tego typu rozwiązania, niektóre nie do końca agile'owe, ale orderów tu nikt raczej rozdawać nie będzie, a królowa jest tylko jedna :P.
Czy jest wsparcie do testowania dostępności w metodach iteracyjnych?
Testy dostępności są oczywiście automatyzowalne, ale w niektórych przypadkach niestety kompletnie nie dają się zastosować w ciasnych agile'owych iteracjach, bo na przykład zajmują kilka dni. Więc by-the-book już postępować nie można. Każda zaś iteracja potencjalnie może nieść zmiany, które będą miały wpływ na pożądaną dostępność systemu. Problem nie występuje w prostych przypadkach, gdy np chcemy przetestować współbieżną dostępność serwisu dla kilku użytkowników. Z drugiej strony testy dostępności typu "pięć dziewiątek" (99,999%) już raczej nie będą dały się tak zgrabnie ogarnąć. Podejście jakie bym w tym przypadku przyjął jest analogiczne do poprzedniego problemu, czyli segmentacja funkcjonalności i uruchamianie testów w tle. Kiedy się skończą to się skończą, jeśli nie możemy poznać ich wyników wcześniej, to trudno, hope for the best i jedziemy dalej z projektem. Jak się testy zakończą to najwyżej będziemy musieli coś poprawić z poprzednich iteracji. Moje podejście jest proste w tym wypadku, jak się nie ma co się lubi, to się lubi co się ma. Jeśli ktoś ma mądrzejsze pomysły to bardzo chętnie posłucham.
Podsumowując tę minę, to jak widać za wiele świetnych rozwiązań do niej nie mam opatentowanych, poza jednym - pamiętać o tych wymaganiach, bo obracając się w świecie feature-driven można je łatwo pominąć. Próbować je przebranżowić na wymagania funkcjonalne i przemycić do backloga projektu w takim płaszczyku. Jeśli się to nie uda to nie płakać tylko spisać je na wiki i zarządzać nimi jak każdym innym ryzykiem projektowym i dla konkretnego przypadku świadomie rozważyć najwłaściwszy model postępowania.
poniedziałek, 7 lipiec 2008
wtorek, 17 czerwiec 2008
Mina 03 - XP vs. inżynieria wymagań
Sukces projektu informatycznego w większości zależy od tego jak bardzo odpowiada on wymaganiom jego użytkowników. Jako informatyk skupiony na wytwarzaniu oprogramowania, często wpadam na problem różnicy między właściwą budową oprogramowania a budową właściwego oprogramowania. Sprawdzone elementy inżynierii wymagań mają na celu wesprzeć nad w wytworzeniu właściwego oprogramowania. Inżynieria wymagań pokrywa takie aspekty projektu jak modelowanie, analiza, zbieranie wymagań, walidacja, zarządzanie.
Aby nie wylecieć na tej minie stawiam sobie takie pytanie:
Które aspekty inżynierii wymagań nie są wspierane przez XP?
Rozwinę trochę to pytanie. Które z aspektów inżynierii wymagań nie są bezpośrednio wspierane lub są prawie pomijane przez praktyki XP lub inne agile'owe praktyki? Moim zdaniem poważnie pominięte lub przynajmniej potraktowane po macoszemu są takie aspekty jak
Tak wiem, wiem, modelowanie jest evil, ale to nieprawda, bo nie jest. Na początku od razu dodam, że nie jest prawdą, że XP nie wspiera w ogóle modelowania, gdyż dobrze wykonywane TDD właśnie zaczyna się od krótkiego modelowania. Zaczynam często nie od testu jednostkowego tylko od kartki i ołówka, potem test, potem implementacja. Ale problem w tym, że takie lokalne modelowanie często mi nie starczało jednak. Rzeczywistość pokazała mi boleśnie, że w wielu przypadkach bez zastosowania "niefunkcjonalnej iteracji zerowej" i bez ogólniejszych modeli zapędzę się sam w kozi róg. I tutaj jest dość ciekawy teren. Z rozmów ze Scottem Amblerem wiem np. że większość aktywistów z listy extremeprogramming@yahoogroups (skądinąd rewelacyjnej listy dyskusyjnej) zapytana na liście prost o modelowanie nie przyzna się do tego, ale tak na prawdę go robią, tylko taki trochę temat tabu się zrobił. I to niedobrze, bo to wprowadza zamęt dla nowooświeconych i osoby takie jak ja muszą to odkrywać na własnej skórze. I potrzeba było lat bym przypomniał sobie czytane kiedyś na stołówce akademickiej artykuły właśnie rzeczonego Scotta Amblera na temat modelowania robionego w sposób lekki.
Analiza jakości wymagań: kompletność, spójność
Nie doszukałem się w praktykach za bardzo elementów, które miałyby traktować na temat kompletności lub spójności wymagań. Wspomniana w poprzednim akapicie iteracja zerowa może pomóc w sprawie spójności, ale też tylko trochę. Techniki z rodziny agile mocno skupiają się na wizualizacji i transparencji procesu. To dotyczy również wymagań (spisywania kart, planowania iteracji, itp), biznes jest angażowany we wszystkie etapy. Ma to ma właśnie na celu sprawienie, by mieć najwięcej szans, by owe niespójności i braki wychwycić. Jednak znów mam doświadczenie takie, że nie bardzo to tak chce działać. Bez działań explicite adresujących te aspekty bardzo łatwo tutaj o problem, który wychodzi potem w sposób bardzo nieprzyjemny dla zespołu.
Zarządzanie: duże ilości, śledzenie
W klasycznej inżynierii wymagań zarządzanie wymaganiami składa się z różnych elementów, na przykład wsparcia dla zarządzania dużymi ilościami wymagań, ewolucji wymagań wymiarze czasowym i wymiarze wersji produktów, śledzenia owych zmian. XP z definicji jest wyjątkowo dobrze dostosowane do wspierania zmian w wymaganiach w czasie. Jednak nie tak dobrze już wygląda kwestia zarządzania dużymi ilościami wymagań, lub śledzenia ich zmian w czasie i pomiędzy rodzinami produktów. O ile to ostatnie jeszcze mnie nie dotknęło, o tyle zarządzanie poważnymi ilościami kart wymagań (User Stories) i ich zmianami w czasie już miałem okazję próbować ogarnąć. Nie jest już tak trywialnym zadaniem jak parę kart w książce Becka. Oczywiście wszystko to jest względnie niepotrzebne jak pracujemy na zasadzie time & materials, ale o tym już wspominałem i nie będę się powtarzał, moi klienci tak nie pracują, i zdziwiłbym się bardzo gdybym okazał sie w tym osamotniony.
Podsumowując minę trzecią. Wykrywanie jej polega na zadaniu sobie na początku projektu tego pytania po pierwsze, które elementy inżynierii wymagań pokrywam swoim procesem, w jakim stopniu, i jakie ryzyko wnoszą do mojego projektu te poszczególne aspekty. Pytania te są dobrym materiałem na porządną retrospekcję releasową na przykład. Następnie na podstawie odpowiedzi na te pytania należy poszukać ewentualnych akcji (ustaleń, praktyk, ...) minimalizujących dane ryzyko, które decydujemy się zmniejszyć. To już jest klasyczne zarządzanie ryzykiem. Ćwiczenie to należy następnie powtórzyć przynajmniej raz na release.
Przepraszam wszystkich stałych czytelników (wiem już, że jednego mam, bo się upomniał o nowy odcinek) za dłuższą przerwę ale c'est la vie sami rozumiecie jak to jest z czasem w dzisiejszych czasach ;). Ale doping na pewno mi pomoże zebrać się szybciej do następnego odcinka, szczególnie że ten nie okazał się za długi.
Aby nie wylecieć na tej minie stawiam sobie takie pytanie:
Które aspekty inżynierii wymagań nie są wspierane przez XP?
Rozwinę trochę to pytanie. Które z aspektów inżynierii wymagań nie są bezpośrednio wspierane lub są prawie pomijane przez praktyki XP lub inne agile'owe praktyki? Moim zdaniem poważnie pominięte lub przynajmniej potraktowane po macoszemu są takie aspekty jak
- modelowanie
- analiza jakości wymagań: kompletność, spójność
- zarządzanie: duże ilości, śledzenie
Tak wiem, wiem, modelowanie jest evil, ale to nieprawda, bo nie jest. Na początku od razu dodam, że nie jest prawdą, że XP nie wspiera w ogóle modelowania, gdyż dobrze wykonywane TDD właśnie zaczyna się od krótkiego modelowania. Zaczynam często nie od testu jednostkowego tylko od kartki i ołówka, potem test, potem implementacja. Ale problem w tym, że takie lokalne modelowanie często mi nie starczało jednak. Rzeczywistość pokazała mi boleśnie, że w wielu przypadkach bez zastosowania "niefunkcjonalnej iteracji zerowej" i bez ogólniejszych modeli zapędzę się sam w kozi róg. I tutaj jest dość ciekawy teren. Z rozmów ze Scottem Amblerem wiem np. że większość aktywistów z listy extremeprogramming@yahoogroups (skądinąd rewelacyjnej listy dyskusyjnej) zapytana na liście prost o modelowanie nie przyzna się do tego, ale tak na prawdę go robią, tylko taki trochę temat tabu się zrobił. I to niedobrze, bo to wprowadza zamęt dla nowooświeconych i osoby takie jak ja muszą to odkrywać na własnej skórze. I potrzeba było lat bym przypomniał sobie czytane kiedyś na stołówce akademickiej artykuły właśnie rzeczonego Scotta Amblera na temat modelowania robionego w sposób lekki.
Analiza jakości wymagań: kompletność, spójność
Nie doszukałem się w praktykach za bardzo elementów, które miałyby traktować na temat kompletności lub spójności wymagań. Wspomniana w poprzednim akapicie iteracja zerowa może pomóc w sprawie spójności, ale też tylko trochę. Techniki z rodziny agile mocno skupiają się na wizualizacji i transparencji procesu. To dotyczy również wymagań (spisywania kart, planowania iteracji, itp), biznes jest angażowany we wszystkie etapy. Ma to ma właśnie na celu sprawienie, by mieć najwięcej szans, by owe niespójności i braki wychwycić. Jednak znów mam doświadczenie takie, że nie bardzo to tak chce działać. Bez działań explicite adresujących te aspekty bardzo łatwo tutaj o problem, który wychodzi potem w sposób bardzo nieprzyjemny dla zespołu.
Zarządzanie: duże ilości, śledzenie
W klasycznej inżynierii wymagań zarządzanie wymaganiami składa się z różnych elementów, na przykład wsparcia dla zarządzania dużymi ilościami wymagań, ewolucji wymagań wymiarze czasowym i wymiarze wersji produktów, śledzenia owych zmian. XP z definicji jest wyjątkowo dobrze dostosowane do wspierania zmian w wymaganiach w czasie. Jednak nie tak dobrze już wygląda kwestia zarządzania dużymi ilościami wymagań, lub śledzenia ich zmian w czasie i pomiędzy rodzinami produktów. O ile to ostatnie jeszcze mnie nie dotknęło, o tyle zarządzanie poważnymi ilościami kart wymagań (User Stories) i ich zmianami w czasie już miałem okazję próbować ogarnąć. Nie jest już tak trywialnym zadaniem jak parę kart w książce Becka. Oczywiście wszystko to jest względnie niepotrzebne jak pracujemy na zasadzie time & materials, ale o tym już wspominałem i nie będę się powtarzał, moi klienci tak nie pracują, i zdziwiłbym się bardzo gdybym okazał sie w tym osamotniony.
Podsumowując minę trzecią. Wykrywanie jej polega na zadaniu sobie na początku projektu tego pytania po pierwsze, które elementy inżynierii wymagań pokrywam swoim procesem, w jakim stopniu, i jakie ryzyko wnoszą do mojego projektu te poszczególne aspekty. Pytania te są dobrym materiałem na porządną retrospekcję releasową na przykład. Następnie na podstawie odpowiedzi na te pytania należy poszukać ewentualnych akcji (ustaleń, praktyk, ...) minimalizujących dane ryzyko, które decydujemy się zmniejszyć. To już jest klasyczne zarządzanie ryzykiem. Ćwiczenie to należy następnie powtórzyć przynajmniej raz na release.
Przepraszam wszystkich stałych czytelników (wiem już, że jednego mam, bo się upomniał o nowy odcinek) za dłuższą przerwę ale c'est la vie sami rozumiecie jak to jest z czasem w dzisiejszych czasach ;). Ale doping na pewno mi pomoże zebrać się szybciej do następnego odcinka, szczególnie że ten nie okazał się za długi.
czwartek, 15 maj 2008
Mina 02 - On-Site Customer albo Whole Team
Kolejną znaną praktyką, która dla mnie była źródłem wielu niespodzianek to było bezpośrednie zaangażowanie klienta w proces wytwórczy oraz transparencja tego procesu. Generalnie chodzi o to by klient był zaangażowany osobiście w projekt. Dotyczy to zarówno procesu analizy jak i spotkań statusowych, projektowych i innych.
Założenie jest takie, że jeśli klient będzie zaangażowany w aktywności niekoniecznie związane z jego odpowiedzialnością to i tak może mieć to dobry skutek, a jeśli do tego będzie uczestniczył w pracach jako żywa dokumentacja (patrz Mina 01) to będzie jeszcze lepiej, bo wtedy my będziemy mieli pewną i rzetelną wiedzę dostępną na zawołanie, a dodatkowo klient będzie się bardziej identyfikował z wytwarzanym produktem (jak to mój prezes dziś podsumował w postaci metafory zamku z piasku: "ta wieżyczka rzeczywiście jest krzywa, ale od tej fosy to Ty się odczep, bo ona jest moja"). Zespół i klient stanowią jedną zgraną i szczęśliwą rodzinę, żyją długo i mają dużo dzieci.
Ponadto według tej praktyki klient obecny na projekcie potrafi podjąć wiążące i ostateczne decyzje do co kształtu, zakresu i szczegółów funkcjonalności, które maja zostać wytworzone. A jeśli jest więcej niż jedna osoba jako "klient" to obowiązuje ich reguła, że przemawiają wspólnym głosem, tzn jeden nie zaprzecza drugiemu.
Tiaaa .... jassssne .. ;)
Zawsze przed dopuszczeniem klienta do tak bliskiej współpracy zadaje sobie pytania - wykrywacze min:
Czy ten klient nie wykorzysta informacji, które zdobędzie na temat zespołu, stylu pracy, efektywności i innych operacyjnych szczegółów firmy przeciw nam w przyszłości?
Call me paranoid, ale zdarzyło mi się, że klient podczas następnych negocjacji zaczął wyciągać na stół dane z których sobie wynioskował, że wcale tyle nie będzie nas to kosztować, bo zespół zrobi to tak i tak i cena ta jest zawyżona, bla bla bla, no i ręce nam opadły, a racji nie miał. No i teraz udowadniaj, że nie jesteś wielbłądem.
Czy klient posiada całą wiedzę jakiej zespół potrzebuje?
Po pierwsze bardzo często osobą najlepiej obeznaną w zawiłych procesach biznesowych, które ma wspierać tworzony system jest jakaś strasznie ważna dla klienta osoba, która oprócz tego projektu ma jeszcze 7 innych obowiązków od których zależy ciągłość biznesu klienta. Siłą rzeczy nie będziemy tej osoby mieli na każdy gwizdek w naszym pokoju, a o zafundowaniu jej biurka i przykuciu jej łańcuchem do niego to możemy sobie pomarzyć.
Z drugiej strony, jeśli dostaniemy inną osobę (mniej ważną), która będzie dla nas miała czas, to czy będzie ona miała całą potrzebną wiedzę? Wątpliwe, ale nawet jeśli tak, to czy będzie ta osoba odpowiednio decyzyjna w sprawach dwuznacznych, by móc na bieżąco podejmować decyzje projektowe, czy będzie musiała z każdą rzeczą latać wyżej albo chwytać za telefon do przyjaciela? Bo w tym przypadku historia informatyki pokazuje, że granie ciągle 50/50 nie sprawdza się zbyt dobrze...
Inaczej zadane pytanie może być tak: czy projekt ten dla klienta jest na tyle istotny by dedykował on do niego odpowiednio dużo (tzn tyle ile my potrzebujemy) czasu swoich kluczowych pracowników? Czy zdaje on sobie sprawę ze skutków tego, że nie będziemy mieli dostępu do takich osób?
Czy klient mówi jednym głosem?
W moim przypadku często było tak, że domena projektu była na tyle obszerna, że nasz klient był co najmniej 2-osobowy, czasem 3-5-osobowy. W takim przypadku kluczowe jest by klient wypowiadał się jednym spójnym głosem komunikując co jest do zrobienia i jak ma działać. Jakie było moje zdziwienie, gdy na jednym ze spotkań wieloosobowy klient zaczął się autentycznie kłócić ze sobą, popatrzeliśmy po sobie, czy przerwiemy im poczekamy ... poczekaliśmy kwadrans i skończyło się na tym, że daną kwestię wyjaśnią na następnym spotkaniu. Nie powiem, by to przyczyniało się do powodzenia projektu ...
W problemie przedstawionym powyżej klient sam się zaangażował w sprzeczkę i postanowił ją rozwiązać. Drugi problem, który spotkałem związany z "jednym głosem" jest podobny do poprzedniego, ale wg mnie znacznie gorszy. Zdarzało mi się lawirować pomiędzy nie rozmawiającymi ze sobą elementami "klienta" i otrzymywać od nich sprzeczne informacje na temat wymagań do konkretnej funkcji. I to często na zasadzie: nie obchodzi mnie co inni chcą, ale mój dział X jest krytyczny i to musi działać tak jak my tego potrzebujemy. I gdzie tu jest One Voice? One Noise jeśli już. I kto mi teraz powie, że informatyka to ścisła dyscyplina inżynieryjna... Nie wiem jak dla innych, ale dla mnie rozwiązywanie problemów klienta na takim poziomie jest dość angażujące i wyczerpujące, potrafi to skonsumować sporo energii i czasu, które mogłyby być skanalizowane o wiele bardziej produktywnie. Jest to klasyczny waste. Poza tym co ja jestem psychoterapeuta czy informatyk?
A może prawda jest taka, że każdy dobry informatyk powinien mieć też składaną (albo dmuchaną) leżankę na którą w odpowiedniej chwili zapraszałby klienta i pytał łagodnym tonem: opowiedz mi o swoich problemach..... Nie żebym strasznie się z tym czuł, ale nie pamiętam tego z rozmowy kwalifikacyjnej, ani też wielkim specjalistą w dziedzinie sie raczej nie czuje... ale może czas zrobić sobie wizytówkę Wojciech Biela - informatyk/psychoterapeuta
Podsumowując nie mówię, że jeśli na któreś z tych pytań nie potrafię odpowiedzieć, lub odpowiedź jest negatywna to nie zapraszam klienta "do środka", albo jak już jest to czymprędzej go wyganiam. Raczej jestem wtedy bardziej czujny, lub stosuję jakieś elementy minimalizujące dane ryzyko. Innymi słowy wchodzę na minę, ale wiedząc że po niej stąpam kroki stawiam ostrożnie i mam na sobie 50kg kevlaru i pełną zbroję płytową ...
Założenie jest takie, że jeśli klient będzie zaangażowany w aktywności niekoniecznie związane z jego odpowiedzialnością to i tak może mieć to dobry skutek, a jeśli do tego będzie uczestniczył w pracach jako żywa dokumentacja (patrz Mina 01) to będzie jeszcze lepiej, bo wtedy my będziemy mieli pewną i rzetelną wiedzę dostępną na zawołanie, a dodatkowo klient będzie się bardziej identyfikował z wytwarzanym produktem (jak to mój prezes dziś podsumował w postaci metafory zamku z piasku: "ta wieżyczka rzeczywiście jest krzywa, ale od tej fosy to Ty się odczep, bo ona jest moja"). Zespół i klient stanowią jedną zgraną i szczęśliwą rodzinę, żyją długo i mają dużo dzieci.
Ponadto według tej praktyki klient obecny na projekcie potrafi podjąć wiążące i ostateczne decyzje do co kształtu, zakresu i szczegółów funkcjonalności, które maja zostać wytworzone. A jeśli jest więcej niż jedna osoba jako "klient" to obowiązuje ich reguła, że przemawiają wspólnym głosem, tzn jeden nie zaprzecza drugiemu.
Tiaaa .... jassssne .. ;)
Zawsze przed dopuszczeniem klienta do tak bliskiej współpracy zadaje sobie pytania - wykrywacze min:
Czy ten klient nie wykorzysta informacji, które zdobędzie na temat zespołu, stylu pracy, efektywności i innych operacyjnych szczegółów firmy przeciw nam w przyszłości?
Call me paranoid, ale zdarzyło mi się, że klient podczas następnych negocjacji zaczął wyciągać na stół dane z których sobie wynioskował, że wcale tyle nie będzie nas to kosztować, bo zespół zrobi to tak i tak i cena ta jest zawyżona, bla bla bla, no i ręce nam opadły, a racji nie miał. No i teraz udowadniaj, że nie jesteś wielbłądem.
Czy klient posiada całą wiedzę jakiej zespół potrzebuje?
Po pierwsze bardzo często osobą najlepiej obeznaną w zawiłych procesach biznesowych, które ma wspierać tworzony system jest jakaś strasznie ważna dla klienta osoba, która oprócz tego projektu ma jeszcze 7 innych obowiązków od których zależy ciągłość biznesu klienta. Siłą rzeczy nie będziemy tej osoby mieli na każdy gwizdek w naszym pokoju, a o zafundowaniu jej biurka i przykuciu jej łańcuchem do niego to możemy sobie pomarzyć.
Z drugiej strony, jeśli dostaniemy inną osobę (mniej ważną), która będzie dla nas miała czas, to czy będzie ona miała całą potrzebną wiedzę? Wątpliwe, ale nawet jeśli tak, to czy będzie ta osoba odpowiednio decyzyjna w sprawach dwuznacznych, by móc na bieżąco podejmować decyzje projektowe, czy będzie musiała z każdą rzeczą latać wyżej albo chwytać za telefon do przyjaciela? Bo w tym przypadku historia informatyki pokazuje, że granie ciągle 50/50 nie sprawdza się zbyt dobrze...
Inaczej zadane pytanie może być tak: czy projekt ten dla klienta jest na tyle istotny by dedykował on do niego odpowiednio dużo (tzn tyle ile my potrzebujemy) czasu swoich kluczowych pracowników? Czy zdaje on sobie sprawę ze skutków tego, że nie będziemy mieli dostępu do takich osób?
Czy klient mówi jednym głosem?
W moim przypadku często było tak, że domena projektu była na tyle obszerna, że nasz klient był co najmniej 2-osobowy, czasem 3-5-osobowy. W takim przypadku kluczowe jest by klient wypowiadał się jednym spójnym głosem komunikując co jest do zrobienia i jak ma działać. Jakie było moje zdziwienie, gdy na jednym ze spotkań wieloosobowy klient zaczął się autentycznie kłócić ze sobą, popatrzeliśmy po sobie, czy przerwiemy im poczekamy ... poczekaliśmy kwadrans i skończyło się na tym, że daną kwestię wyjaśnią na następnym spotkaniu. Nie powiem, by to przyczyniało się do powodzenia projektu ...
W problemie przedstawionym powyżej klient sam się zaangażował w sprzeczkę i postanowił ją rozwiązać. Drugi problem, który spotkałem związany z "jednym głosem" jest podobny do poprzedniego, ale wg mnie znacznie gorszy. Zdarzało mi się lawirować pomiędzy nie rozmawiającymi ze sobą elementami "klienta" i otrzymywać od nich sprzeczne informacje na temat wymagań do konkretnej funkcji. I to często na zasadzie: nie obchodzi mnie co inni chcą, ale mój dział X jest krytyczny i to musi działać tak jak my tego potrzebujemy. I gdzie tu jest One Voice? One Noise jeśli już. I kto mi teraz powie, że informatyka to ścisła dyscyplina inżynieryjna... Nie wiem jak dla innych, ale dla mnie rozwiązywanie problemów klienta na takim poziomie jest dość angażujące i wyczerpujące, potrafi to skonsumować sporo energii i czasu, które mogłyby być skanalizowane o wiele bardziej produktywnie. Jest to klasyczny waste. Poza tym co ja jestem psychoterapeuta czy informatyk?
A może prawda jest taka, że każdy dobry informatyk powinien mieć też składaną (albo dmuchaną) leżankę na którą w odpowiedniej chwili zapraszałby klienta i pytał łagodnym tonem: opowiedz mi o swoich problemach..... Nie żebym strasznie się z tym czuł, ale nie pamiętam tego z rozmowy kwalifikacyjnej, ani też wielkim specjalistą w dziedzinie sie raczej nie czuje... ale może czas zrobić sobie wizytówkę Wojciech Biela - informatyk/psychoterapeuta
Podsumowując nie mówię, że jeśli na któreś z tych pytań nie potrafię odpowiedzieć, lub odpowiedź jest negatywna to nie zapraszam klienta "do środka", albo jak już jest to czymprędzej go wyganiam. Raczej jestem wtedy bardziej czujny, lub stosuję jakieś elementy minimalizujące dane ryzyko. Innymi słowy wchodzę na minę, ale wiedząc że po niej stąpam kroki stawiam ostrożnie i mam na sobie 50kg kevlaru i pełną zbroję płytową ...
poniedziałek, 28 kwiecień 2008
Mina 01 - Dokumentacja: User Stories i Testy
Podstawą metodyk lekkich jest zasada "travel light", gdzie indziej wyrażana jako "eliminate waste", generalnie chodzi o to, żeby pozbywać się bagażu produktów i czynności, które powodują że proces jest ociężały i zawiera bardzo duży nakład prac okołoprojektowych, które nie skutkują krótko ani długoterminowo wartościami dodanymi dla projektu lub wartości te są mierne. Pierwszą rzeczą o której sie dowiedziałem, gdy usłyszałem o XP to było "brak dokumentacji". I tak rzeczywiście postrzegany jest ten proces przez innych. Wielokrotnie słyszałem komentarz "aha to ta metoda gdzie piszecie kod bez dokumentacji tak?" co ciekawe wypowiadany zarówno w pozytywnym jak i negatywnym kontekście.
Tak więc powszechną opinią jest, że dokumentacji w projektach agileowych powinno w zasadzie nie być per se, jej rolę mają przejąć:
Czy taką dokumentacją "w locie" opisze się każdy kawałek skomplikowanego systemu?
Dla przykładu. W zależności od skomplikowania są potrzebne poglądowe dokumenty opisujące architekturę systemu "z lotu ptaka". Przeważnie trudno się obejść bez dokumentu wizji systemu. Trudno obejść się bez słowno-muzycznych opisów do skomplikowanych procedur logistycznych. Takie procedury oczywiście koniecznie powinny być wyrażone w postaci testów akceptacyjnych (FitNesse na przykład), lecz uważam że oprócz tabelek z możliwymi stanami systemu krótki opis danego przypadku, mocno podnosi wartość dokumentacyjną takiego testu.
Oczywiście do dyskusji jest kiedy te dokumenty mają powstać oraz jak obszerne mają być, i tutaj moim zdaniem tkwi klucz do pojęcia lekkości.
Czy wszyscy klienci grają fair i nie nadużywają procesu do niekończących się zmian
Jeśli pracujemy na kontrakt typu T&M (time & materials) to problemu nie ma, przynajmniej dla nas. Jednak większość z nas, w tym i ja, nie ma takiego luksusu. Więc tak, z jednej strony mamy proces, w którym chcemy odraczać decyzje, nie spisywać wszystkiego na papier, po prostu naszą dokumentacją i źródłem wiedzy jest nasz klient i on mówi czy w prawo czy w lewo. Super. Z drugiej zaś strony podpisaliśmy jakiś śmieszny papier, albo częściej jak to było w moim przypadku, ktoś to za mnie dawno temu zrobił i tak na prawdę to niezależnie co, ale za miesiąc to nam sie budżet na projekt skończy.
Miałem klientów, którzy to rozumieli i szło dobrze, rozumieli że jesteśmy elastyczni i nie muszą wszystkie mieć na ostatni guzik na start projektu i jak coś im się nie spodoba to będą mogli to zmienić, ale rozumieli, że jak coś wymyślą strasznego to będą musieli renegocjować, bo powyżej własnego tyłka nie podskoczymy.
Niestety spotkałem się też z brakiem takiego zrozumienia, lub może z perfidnym zrozumieniem oraz zrozumieniem jak można to wykorzystać dla własnej krótkoterminowej korzyści (tak, tak, łamiąc zasadę "repeat business"). Nie wiem, ale wolę myśleć, że jednak był to brak zrozumienia. Brak dokumentów (lub testów akceptacyjnych w ich roli) stwierdzających jak dana funkcjonalność ma działać powoduje, że zespół staje w sytuacji bez wyjścia. Odbieranie prac przez klienta na koniec iteracji i akceptacja ad-hoc też może niewiele przynieść jeśli na koniec projektu klient powie: "no dobra, a w umowie napisaliście, że będzie to to to i to".
Tak, jest to często sprawa kontraktu niedopasowanego do metodyki realizacji projektu, ale właśnie w tym jest problem. Nie pracujemy w laboratoryjnych, kontrolowanych i sterylnych warunkach, tylko w swoich firmach, gdzie cuda na kiju się dzieją. Do niedawna nie miałem żadnego wpływu na to co jest w kontraktach które podpisujemy, czy to znaczy że nie mogłem wdrażać praktyk XP? Myślę że mogłem, tylko jak zawsze, trzeba je wdrażać z głową. I nawet jak teraz mam na to wpływ to jednak nie znalazłem w sobie tyle siły perswazji, by jakiegoś klienta przekonać do T&M. Kontrakty to osobna paskudna mina, którą zajmę się później.
Czy są dostępne lekkie narzędzia wspierające ten typ dokumentacji?
Do kart wymagań używałem w zależności od uwarunkowań projektu: od białej tablicy, magnesów, kartek i mazaków przez XPlanner po Excela. Do testów akceptacyjnych od Canoo WebTest przez Selenium i FitNesse po NUnitForms. Do rozmów z klientem po prostu edytor tesktu do spisania notatek ze spotkania.
Każde z tych narzędzi jednak ma braki. Tablica jest super ale jak masz rozproszony zespół to robi się bezużyteczna. W tabelkach FitNesse super wyraża się wymagania ale napisanie warstw pośredniczących, wypracowanie DSLa, jeśli chcemy używać go do dokumentacji pochłania dużo czasu i energii.
Miało być tak lekko, a ja czasem czuje dość duży ciężar mimo wszystko.
Czy tego typu dokumentacja pokryje NFR?
Wymagania niefunkcjonalne (non-functional requirements) od zawsze są zmorą jeśli chodzi o testowanie. W szczególności zaś jeśli chodzi o zautomatyzowane testowanie z jakim mamy do czynienia tutaj. Dokumentacja w postaci testów akceptacyjnych czy integracyjnych musi w takim razie wyrazić takie aspekty niefunkcjonalne jak dostępność (np. 99,999%), jakość interfejsu użytkownika (usability) czy spełnienie określonych norm branżowych. Testami NFR zajmę się w oddzielnym temacie, więc nie będę sie rozwodził. Chciałem tylko przy tej okazji powiedzieć, że często potrzeba dokumentu, który takie wymagania po prostu w paru słowach opisze, do którego będzie się można później odnieść.
Czy pamięć grupowa rzeczywiście da radę?
Osobiście uważam że nie. Co więcej popiera to ostatnie moje doświadczenie. "Hmmm no dobra, to teraz rozbijamy te duże karty do następnego realeasu, hmmm czy ktoś pamięta co ta karta znaczyła, rozmawialiśmy o niej 2 miesiące temu." Niestety nikt nie pamiętał. Koniec tematu.
Zamiast podsumowania
Nie będę podsumowywał, bo chcę iść spać. Może coś jutro dodam jeszcze pod wpływem komentarzy, bo czuje że nie wyczerpałem tematu. Powiem tylko tak, jestem wielkim zwolennikiem bardzo lekkich form dokumentacji, najlepiej w formie testów lub przynajmniej zwięzłych notatek, powiązanych hipertekstowo, świetnie się do tego nadaje wiki. Szczególnie dobrze gra z tym FitNesse, który jednocześnie jest platformą do testów akceptacyjnych i wiki, dodam tylko że z FitNesse można z powodzeniem odpalać testy Selenium przez Selenium RC i wtedy jest full wypas. Problem z "travel light" jest taki ze nie bez przyczyny jest to "travel light" a nie "travel naked", analogicznie Mary Poppendieck mówi "eliminate waste" a nie "eliminate everything". Tylko nasz narodowy idol z Podlasia twierdzi, że "wszystko zlikwiduje", ale prezydentem nie został, więc jak widać na przykładzie podejście to jest nieskuteczne. Pytanie w takim razie jak rozeznać piernik od wiatraka to oddzielna bajka, nie na dziś.
Tak więc powszechną opinią jest, że dokumentacji w projektach agileowych powinno w zasadzie nie być per se, jej rolę mają przejąć:
- ustne przekazy
- mechanizmy społeczne takie jak pamięć grupowa
- karty wymagań (user stories), które same w sobie są "zwięzłą zapowiedzią dalszej rozmowy"
- ciągła komunikacja z klientem
- testy akceptacyjne - dokumentacja funkcjonalna
- testy jednostkowe oraz integracyjne - dokumentacja architektoniczna
Czy taką dokumentacją "w locie" opisze się każdy kawałek skomplikowanego systemu?
Dla przykładu. W zależności od skomplikowania są potrzebne poglądowe dokumenty opisujące architekturę systemu "z lotu ptaka". Przeważnie trudno się obejść bez dokumentu wizji systemu. Trudno obejść się bez słowno-muzycznych opisów do skomplikowanych procedur logistycznych. Takie procedury oczywiście koniecznie powinny być wyrażone w postaci testów akceptacyjnych (FitNesse na przykład), lecz uważam że oprócz tabelek z możliwymi stanami systemu krótki opis danego przypadku, mocno podnosi wartość dokumentacyjną takiego testu.
Oczywiście do dyskusji jest kiedy te dokumenty mają powstać oraz jak obszerne mają być, i tutaj moim zdaniem tkwi klucz do pojęcia lekkości.
Czy wszyscy klienci grają fair i nie nadużywają procesu do niekończących się zmian
Jeśli pracujemy na kontrakt typu T&M (time & materials) to problemu nie ma, przynajmniej dla nas. Jednak większość z nas, w tym i ja, nie ma takiego luksusu. Więc tak, z jednej strony mamy proces, w którym chcemy odraczać decyzje, nie spisywać wszystkiego na papier, po prostu naszą dokumentacją i źródłem wiedzy jest nasz klient i on mówi czy w prawo czy w lewo. Super. Z drugiej zaś strony podpisaliśmy jakiś śmieszny papier, albo częściej jak to było w moim przypadku, ktoś to za mnie dawno temu zrobił i tak na prawdę to niezależnie co, ale za miesiąc to nam sie budżet na projekt skończy.
Miałem klientów, którzy to rozumieli i szło dobrze, rozumieli że jesteśmy elastyczni i nie muszą wszystkie mieć na ostatni guzik na start projektu i jak coś im się nie spodoba to będą mogli to zmienić, ale rozumieli, że jak coś wymyślą strasznego to będą musieli renegocjować, bo powyżej własnego tyłka nie podskoczymy.
Niestety spotkałem się też z brakiem takiego zrozumienia, lub może z perfidnym zrozumieniem oraz zrozumieniem jak można to wykorzystać dla własnej krótkoterminowej korzyści (tak, tak, łamiąc zasadę "repeat business"). Nie wiem, ale wolę myśleć, że jednak był to brak zrozumienia. Brak dokumentów (lub testów akceptacyjnych w ich roli) stwierdzających jak dana funkcjonalność ma działać powoduje, że zespół staje w sytuacji bez wyjścia. Odbieranie prac przez klienta na koniec iteracji i akceptacja ad-hoc też może niewiele przynieść jeśli na koniec projektu klient powie: "no dobra, a w umowie napisaliście, że będzie to to to i to".
Tak, jest to często sprawa kontraktu niedopasowanego do metodyki realizacji projektu, ale właśnie w tym jest problem. Nie pracujemy w laboratoryjnych, kontrolowanych i sterylnych warunkach, tylko w swoich firmach, gdzie cuda na kiju się dzieją. Do niedawna nie miałem żadnego wpływu na to co jest w kontraktach które podpisujemy, czy to znaczy że nie mogłem wdrażać praktyk XP? Myślę że mogłem, tylko jak zawsze, trzeba je wdrażać z głową. I nawet jak teraz mam na to wpływ to jednak nie znalazłem w sobie tyle siły perswazji, by jakiegoś klienta przekonać do T&M. Kontrakty to osobna paskudna mina, którą zajmę się później.
Czy są dostępne lekkie narzędzia wspierające ten typ dokumentacji?
Do kart wymagań używałem w zależności od uwarunkowań projektu: od białej tablicy, magnesów, kartek i mazaków przez XPlanner po Excela. Do testów akceptacyjnych od Canoo WebTest przez Selenium i FitNesse po NUnitForms. Do rozmów z klientem po prostu edytor tesktu do spisania notatek ze spotkania.
Każde z tych narzędzi jednak ma braki. Tablica jest super ale jak masz rozproszony zespół to robi się bezużyteczna. W tabelkach FitNesse super wyraża się wymagania ale napisanie warstw pośredniczących, wypracowanie DSLa, jeśli chcemy używać go do dokumentacji pochłania dużo czasu i energii.
Miało być tak lekko, a ja czasem czuje dość duży ciężar mimo wszystko.
Czy tego typu dokumentacja pokryje NFR?
Wymagania niefunkcjonalne (non-functional requirements) od zawsze są zmorą jeśli chodzi o testowanie. W szczególności zaś jeśli chodzi o zautomatyzowane testowanie z jakim mamy do czynienia tutaj. Dokumentacja w postaci testów akceptacyjnych czy integracyjnych musi w takim razie wyrazić takie aspekty niefunkcjonalne jak dostępność (np. 99,999%), jakość interfejsu użytkownika (usability) czy spełnienie określonych norm branżowych. Testami NFR zajmę się w oddzielnym temacie, więc nie będę sie rozwodził. Chciałem tylko przy tej okazji powiedzieć, że często potrzeba dokumentu, który takie wymagania po prostu w paru słowach opisze, do którego będzie się można później odnieść.
Czy pamięć grupowa rzeczywiście da radę?
Osobiście uważam że nie. Co więcej popiera to ostatnie moje doświadczenie. "Hmmm no dobra, to teraz rozbijamy te duże karty do następnego realeasu, hmmm czy ktoś pamięta co ta karta znaczyła, rozmawialiśmy o niej 2 miesiące temu." Niestety nikt nie pamiętał. Koniec tematu.
Zamiast podsumowania
Nie będę podsumowywał, bo chcę iść spać. Może coś jutro dodam jeszcze pod wpływem komentarzy, bo czuje że nie wyczerpałem tematu. Powiem tylko tak, jestem wielkim zwolennikiem bardzo lekkich form dokumentacji, najlepiej w formie testów lub przynajmniej zwięzłych notatek, powiązanych hipertekstowo, świetnie się do tego nadaje wiki. Szczególnie dobrze gra z tym FitNesse, który jednocześnie jest platformą do testów akceptacyjnych i wiki, dodam tylko że z FitNesse można z powodzeniem odpalać testy Selenium przez Selenium RC i wtedy jest full wypas. Problem z "travel light" jest taki ze nie bez przyczyny jest to "travel light" a nie "travel naked", analogicznie Mary Poppendieck mówi "eliminate waste" a nie "eliminate everything". Tylko nasz narodowy idol z Podlasia twierdzi, że "wszystko zlikwiduje", ale prezydentem nie został, więc jak widać na przykładzie podejście to jest nieskuteczne. Pytanie w takim razie jak rozeznać piernik od wiatraka to oddzielna bajka, nie na dziś.
Wstępna Lista Tematów Minolubnych
Ulegając namowie komentatorów, spisałem minogenne tematy o których już do tej pory albo pisałem wraz z Lechem Madeyskim (nota bene mam wielką nadzieje, że włączy sie do dyskusji) albo mówiłem podczas Agile Underground. Niestety systematyzacja tego zajęła mi trochę czasu i nie zdążyłem opisać pierwszej miny jak obiecałem, nadrobię to jutro.
Lista nie jest długa, ale jak zacząłem ja pisać to zacząłem rozmyślać, a to wiadomo nie prowadzi do niczego dobrego, no i nie wiadomo środek nocy sie zrobił ...
Kolejność tematów nieistotna
Lista nie jest długa, ale jak zacząłem ja pisać to zacząłem rozmyślać, a to wiadomo nie prowadzi do niczego dobrego, no i nie wiadomo środek nocy sie zrobił ...
Kolejność tematów nieistotna
- dokumentacja: ustna dokumentacja, User Stories, testy
- On-Site Customer lub Whole Team
- praktyki XP vs. inżynieria wymagań
- wymagania niefunkcjonalne
- programowanie parami
- Test-Driven Development
- ciągłe i przyrostowe projektowanie
- współdzielony kod
- brak "manuala" do metodyk agile
- "it's about social change"
- wdrażanie praktyk XP
- wartości ekonomiczne
- kontrakty
- komunikacja
- plan vs. planowanie
Disclaimer Do Poradnika Młodego Sapera
Miny, które będę opisywał w tym cyklu dla niektórych mogą się wydawać trywialne do wykrycia, no cóż, teraz dla mnie też wiele z nich jest trywialnych, jednak większość z nich nauczyłem sie wykrywać "the hard way", więc uważam że jest pożyteczne spisanie i rozmawianie o tych prostych sprawach też, by móc później z pełnym zrozumieniem mówić o trudniejszych. My - zwolennicy metodyk lekkich - jako społeczność w Polsce nie za bardzo jeszcze istniejemy więc myślę, że takie rozmowy o podstawach się nam przydadzą.
Co więcej nie zamierzam się za bardzo rozpisywać na temat tego co zrobić z taką miną jak już się ją wykryje, z punktu widzenia tej serii najbardziej wartościowe wydaje mi się jak znaleźć taką minę, gdzie w procesie twórczym można się ich spodziewać i jakie są ich pierwsze symptomy.
Jeśli nie to to mam ogromną nadzieję, że te opisy przynajmniej oszczędzą (niektórych) problemów tym, którzy dopiero zaczynają okrywać dodane wartości tego ciągle rozwijającego się podejścia do inżynierii oprogramowania jakim jest nurt agile software development.
Co więcej nie zamierzam się za bardzo rozpisywać na temat tego co zrobić z taką miną jak już się ją wykryje, z punktu widzenia tej serii najbardziej wartościowe wydaje mi się jak znaleźć taką minę, gdzie w procesie twórczym można się ich spodziewać i jakie są ich pierwsze symptomy.
Jeśli nie to to mam ogromną nadzieję, że te opisy przynajmniej oszczędzą (niektórych) problemów tym, którzy dopiero zaczynają okrywać dodane wartości tego ciągle rozwijającego się podejścia do inżynierii oprogramowania jakim jest nurt agile software development.
piątek, 25 kwiecień 2008
Prequel Poradnika Młodego Sapera
Podążając za namową uczestników iteracji pierwszej Agile Underground w Krakowie zdecydowałem się rozpocząć spisywanie i prowokowanie do dyskusji na temat problemów związanych z wprowadzaniem agile'owych praktyk w warunkach bojowych.
Zdecydowałem się zorganizować tę serię tak jak prezentację/dyskusję podczas Agile Underground. Każdy wpis będzie dotyczył jednej miny. Mina jak to mina, ma tendencję efektownie wybuchać gdy się na nią wejdzie, w czym związane są zwykle pewne obrażenia, czasem poważne, nawet krytyczne. O ile analogie w inżynierii oprogramowania do tej pory wyrządziły raczej więcej szkód niż pożytku to tę analogie uważam za trafną i nieszkodliwą. Miny, które zamierzam tutaj przedstawiać, mogą być powodem poważnych kłopotów podczas realizacji projektów, komplikacji pracy zespołów lub ich rozpadu. Niektóre takie miny są niegroźne w skutkach bezpośrednich, ale za to napsują tyle powietrza wkoło, że potem nikt nie chce słyszeć o kolejnym projekcie tymi dziwnymi metodami.
Zdecydowana większość opisów i przemyśleń bierze początek w mojej praktyce zawodowej, ale również jest owocem moich rozmów na różnych forach czy konferencjach, w szczególności z dr Lechem Madeyskim z Politechniki Wrocławskiej, moim serdecznym kolegą z którym napisałem kiedyś artykuł na konferencję, który z kolei stał się podstawą do rzeczonej prezentacji na Agile Underground.
Co bystrzejsi czytelnicy zdążyli się już zorientować, że do prowadzenia bloga wybrałem nasz język ojczysty. Przyczynę dlaczego tak wybrałem wyjawię w odpowiednim czasie ;). Wiem jednak, że będę tego żałował bo pewnie już przy pierwszym wpisie będę się skręcał wymyślając tłumaczenia angielskich sformułowań, więc bardzo proszę Was o wyrozumiałość, gdy będę po polsku odmieniał słowo agile czy bez tłumaczenia używał terminu Stand-Up Meeting czy Daily Scrum. Bo wybaczcie ale zwinny to był mój kot, dopóki mojej żony pies go nie przegonił z mieszkania. Są rzeczy, których tłumaczenia bym nie przeżył.
Pierwszy wpis obiecuję już w ten weekend. Bardzo będę się starał trzymać pewną rytmikę wpisów, bo wiem że taka regularność będzie dobra dla obu stron, jednak dziać się to raczej będzie w moim tzw. czasie wolnym, czyli gdy uśpiłem już i dzieci i żonę, a udało mi się przy tym samemu nie zasnąć. Chciałbym obiecać przynajmniej jeden wpis na 2 tygodnie. Myślę, że na tyle mogę się zadeklarować.
Zdecydowałem się zorganizować tę serię tak jak prezentację/dyskusję podczas Agile Underground. Każdy wpis będzie dotyczył jednej miny. Mina jak to mina, ma tendencję efektownie wybuchać gdy się na nią wejdzie, w czym związane są zwykle pewne obrażenia, czasem poważne, nawet krytyczne. O ile analogie w inżynierii oprogramowania do tej pory wyrządziły raczej więcej szkód niż pożytku to tę analogie uważam za trafną i nieszkodliwą. Miny, które zamierzam tutaj przedstawiać, mogą być powodem poważnych kłopotów podczas realizacji projektów, komplikacji pracy zespołów lub ich rozpadu. Niektóre takie miny są niegroźne w skutkach bezpośrednich, ale za to napsują tyle powietrza wkoło, że potem nikt nie chce słyszeć o kolejnym projekcie tymi dziwnymi metodami.
Zdecydowana większość opisów i przemyśleń bierze początek w mojej praktyce zawodowej, ale również jest owocem moich rozmów na różnych forach czy konferencjach, w szczególności z dr Lechem Madeyskim z Politechniki Wrocławskiej, moim serdecznym kolegą z którym napisałem kiedyś artykuł na konferencję, który z kolei stał się podstawą do rzeczonej prezentacji na Agile Underground.
Co bystrzejsi czytelnicy zdążyli się już zorientować, że do prowadzenia bloga wybrałem nasz język ojczysty. Przyczynę dlaczego tak wybrałem wyjawię w odpowiednim czasie ;). Wiem jednak, że będę tego żałował bo pewnie już przy pierwszym wpisie będę się skręcał wymyślając tłumaczenia angielskich sformułowań, więc bardzo proszę Was o wyrozumiałość, gdy będę po polsku odmieniał słowo agile czy bez tłumaczenia używał terminu Stand-Up Meeting czy Daily Scrum. Bo wybaczcie ale zwinny to był mój kot, dopóki mojej żony pies go nie przegonił z mieszkania. Są rzeczy, których tłumaczenia bym nie przeżył.
Pierwszy wpis obiecuję już w ten weekend. Bardzo będę się starał trzymać pewną rytmikę wpisów, bo wiem że taka regularność będzie dobra dla obu stron, jednak dziać się to raczej będzie w moim tzw. czasie wolnym, czyli gdy uśpiłem już i dzieci i żonę, a udało mi się przy tym samemu nie zasnąć. Chciałbym obiecać przynajmniej jeden wpis na 2 tygodnie. Myślę, że na tyle mogę się zadeklarować.
Subskrybuj:
Posty (Atom)
