e X treme P rogramming

1. eXtreme Programming

2. Ta prezentacja nie będzie dotyczyła całości zagadnienia jakim jest XP, ponieważ ramy czasowe na to nie pozwalają. Zatem skupimy się przede wszystkim na ideologii - przemilczając szczegóły, plany i dokładne opisy.

3. Historia • Twórcy: Kent Beck,Ward Cunningham • Pierwsze prace: początek lat 90' • Pierwsze użycie: 1996, DaimlerChrysler

4. Czym jest XP? XP to przede wszystkim przemyślane i zdyscyplinowane podejście do produkcji oprogramowania.

5. Cytując słowa samego Beck'a :"XP to styl tworzenia oprogramowania, który zakłada maksymalizację zysków wynikających z zastosowania zaawansowanych technik programistycznych, komunikacji i pracy w zespole”

6. Do rzeczy! XP, zresztą jak wiele innych zagadnień w informatycznym półświatku, można porównać do puzzli - aby zobaczyć cały obrazek należy ułożyć wszystkie kawałki.

7. Aby poznać XP należy zrozumieć trzy główne filary tej metodologii oraz ich wzajemne relacje. Oto one: I. Wartości => II. Zasady => III. Praktyki

8. Wartości • Komunikacja • Prostota • Sprzężenie zwrotne • Odwaga • Szacunek

9. Komunikacja Komunikacja jest niezbędna do pracy w zespole w ogólności - nie tylko przy projektach informatycznych. Jej brak powoduje niewłaściwe lub niepotrzebne wykonywanie zadań, utrudnia a czasem nawet uniemożliwia wykrywanie i naprawianie błędów oraz powoduje wydłużanie czasu rozwiązywania problemów.

10. Brak komunikacji znakomicie oddaje stary ale jakże jary rysunek:

11. Prostota Chodzi oto by eliminować zbyteczną złożoność, która nie przekłada się na rozwiązanie problemu. Należy unikać nadgorliwego uogólniania naszych rozwiązań wyrastających poza ramy problemu a zwiększających złożoność tworzonej aplikacji.

12. W związku z prostotą dwa mądre cytaty: Albert Enstein:" Wszystko trzeba robić tak prosto, jak to tylko jest możliwe, ale nie prościej."Kent Beck:"Usprawnienie komunikacji ułatwia osiągnięcie prostoty poprzez eliminowanie zbędnych lub nadmiernie złożonych wymagań. Z drugiej strony - uproszczenie systemu ogranicza ilość komunikacji niezbędnej do jego tworzenia."

13. Sprzężenie zwrotne Cytat Jacka ( truesolutions - patrz źródła):"Musimy wykonać ruch, żeby zobaczyć jego wynik. Musimy zapytać, aby poznać odpowiedz."    

14. Częsty kontakt z klientem sprawia, że możemy sprawniej korygować tworzoną aplikację tak, aby ona lepiej przybliżała jego oczekiwania. Powtarzając za starą polską mądrością ludową:"Pańskie oko konia tuczy"

15. Odwaga Jacek:"To sztuka mówienia prawdy, nawet kiedy jest nieprzyjemna. To sztuka przyznania się do błędu, a także umiejętność powiedzenia tego samego współpracownikowi."

16. Beck:"Odważne odrzucanie błędnych rozwiązań umożliwia dążenie do prostoty. Odważne poszukiwanie jasnych i przejrzystych odpowiedzi ułatwia uzyskiwanie sprzężenia zwrotnego."

17. Szacunek Szacunek jest ogromnie ważną sprawą w pracy zespołu. Nie może być sytuacji, w których ktoś próbuje pokazywać kto tu rządzi, gdyż psuje to kontakty w grupie, a co za tym idzie, ogólną komunikację.

18. W zespole musi panować miła atmosfera, należy liczyć się ze zdaniem współpracowników niepróbując ich na każdym kroku ośmieszać lub  pokazywać, że  "są głupi i słabi", po to by wzmacniać swoją pozycję.

19. Zasady • Przepływ • Możliwości • Redundancja • Porażka • Jakość • Zasada małych kroków • Akceptowalna odpowiedzialność • Człowieczeństwo • Ekonomia • Wspólna korzyść • Samopodobieństwo • Doskonalenie • Różnorodność • Refleksja

20. Oczywiście nie wszystkie z wymienionych wcześniej zasad muszą być wykorzystywane podczas pracy nad projektem - jest to sprawa indywidualna, jednak i tak, wiele z nich stosujemy podświadomie.

21. Człowieczeństwo "Wiedzę można uzupełnić - zmienić charakter jest trudno." Dlatego lepiej jest mieć w zespole osoby o mniejszych(ale nie popadając w skrajność) kwalifikacjach za to dobrze pracujące w grupie, niż fachowców, z którymi nie idzie się dogadać.

22. Ekonomia Jacek:"Zasada jest prosta - najpierw rozwiązujemy problemy, które mają największy wpływ na komercyjny sukces naszego oprogramowania." Beck:"Oprogramowanie jest tym cenniejsze, im szybciej przynosi zysk."

23. Wspólna korzyść Musimy pamiętać że nie jesteśmy sami w zespole, a na efektach naszej pracy mogą bazować inni. Dlatego też, należy rezygnować z indywidualnych upodobań i robić wszystko z uwzględnieniem interesów powiązanych z nami osób.

24. Samopodobieństwo Chodzi oto by próbować stosować/przedłużać pewne sprawdzone rozwiązania w różnych skalach. Np. Jeżeli dzień rozpoczynamy od planowania zadań a potem ich wykonywania, to przedłużając to postępowanie na długość miesiąca będziemy: planować zadania na początku każdego miesiąca i przez pozostały czas je wykonywać. (oczywiście nie zaniechując codziennego planowania zadań bieżących)

25. Doskonalenie Jacek:"W XP projektuje oraz koduje się przyrostowo, pracuje z prototypem i słucha użytkowników, w ten sposób dążąc do doskonałości." Zamiast filozofować nad problemami, które pewnie nigdy się nie pojawią, lepiej wziąć się do pracy, gdyż najlepsze pomysły zazwyczaj i tak pochodzą od użytkowników końcowych.

26. Różnorodność Jacek:"Nie ma nic bardziej kreatywnego niż burza mózgów - najlepiej, gdy ścierają się skrajnie różne podejścia do tematu. Tylko w taki sposób możemy poznać prawdziwe “za” i “przeciw” dla każdego problemu"

27. Refleksja Jacek:"(...) okresowa analiza kodu, refaktoryzacja, przyznanie się do błędów koncepcyjnych - wszystko to jest bardzo ważnym elementem cyklu tworzenia oprogramowania. Często trzeba się przyznać do błędu czy przeoczenia, jednak w prawidłowo funkcjonujących zespołach (...) jest to normalna, niestresująca procedura."

28. Przepływ Jacek:"Zasada przepływu mówi nam o konieczności ciągłej integracji kodu - im częściej, tym lepiej. Im dłużej będziemy zwlekać z integracją, tym większe problemy możemy napotkać, gdy przyjdzie nam w końcu połączyć poszczególne części aplikacji w jedną całość."

29. Możliwości W sytuacjach problemowych nie można "usiąść i płakać", ale powinniśmy  zdystansować się odpowiednio i zacząć poszukiwać innych możliwości (np. przez wykorzystanie innych/nowych technologii)

30. Redundancja Beck:"Każdy z trudnych, fundamentalnych problemów w rozwoju oprogramowania powinien być rozwiązany na kilka rozmaitych sposobów." Po to by w zanadrzu,w razie kryzysu, gdy nie będzie czasu na szukanie alternatywnych rozwiązań, mieć asa w rękawie i nie być skazanym na upadek projektu. Poza tym, gdy mamy kilka rozwiązań, pomaga nam to lepiej zrozumieć naturę problemu.

31. Porażka Porażki poza gorzkim smakiem niosą w sobie coś jeszcze - nierzadko trudną do zdobycia w inny sposób wiedzę. Dlatego nie należy załamywać rąk tylko postarać się wyciągnąć wnioski na przyszłość i zacząć od nowa - lepiej.

32. Jakość Metodologia XP, co zobaczymy w Praktykach, stawia na jakość tworzonego oprogramowania. Jakość widoczną z punktu widzenia : - Klienta: wysoka wydajność, mała zasobożerność, mała ilość błędów  oraz duża funkcjonalność, - Producenta: przejrzysty i łatwo pielęgnowalny kod.

33. Zasada małych kroków W zasadzie tej chodzi o to, aby robić małe zmiany i czekać na feedback. Budowa aplikacji przypomina trochę wędrówkę w górę po schodach. Nie warto robić dużych skoków - ryzykownych i wymagających wielkich nakładów. Zmiany powinno się wprowadzać stopniowo po to również by spokojnie przyzwyczaić klienta i w razie jego wątpliwości móc je łatwo wycofać.

34. Akceptowalna odpowiedzialność Beck:"Odpowiedzialność nie może zostać wymuszona, można ją jedynie zaakceptować." Np. Wymaganie od osoby przyjmującej zadanie, podanie czasu jego zakończenia.

35. Praktyki • Samowystarczalny zespół • Rotacja Programistów po systemie • Spotkania na stojąco • Refaktoring • Energiczna praca • Wspólne środowisko pracy • Programowanie w parach • Testy jednostkowe • User stories • Iteracyjne poprawianie • Karty CRC

36. Samowystarczalny zespół W zespole zawsze powinny znajdować się wszystkie osoby niezbędne do wykonania danego zadania. Jeżeli w jakimś momencie brakuje jakiegoś specjalisty to powinien on dołączyć do zespołu i pozostać tak długo jak będzie potrzebny.

37. Rotacja programistów po systemie Rotacja programistów powoduje rozproszenie wiedzy. Dzięki temu wszyscy programiści lepiej widzą cały system, co ułatwia  wykrywanie błędów, wykonywanie nowych zadań a ponadto, człowiek odchodzący z zespołu nie zabiera ze sobą wiedzy na temat tego co robił - gdyż wszyscy ją posiadają.

38. Spotkania na stojąco Organizowanie codziennych porannych spotkań na stojąco całego zespołu powoduje zakomunikowanie problemów, rozwiązań oraz skupienia uwagi całego zespołu na owych sprawach. Osoby stojąc tworzą okrąg by uniknąć długich dyskusji. Ponadto spotkania zazwyczaj są krótkie, ponieważ człowiek nie linux - stać długo nie może...

39. Refaktoring Dr Marciniak:"Złożoność zabija." Refaktoring powinien być dokonywany po każdej iteracji i/lub implementacji danej funkcjonalności, w celu uproszczenia, rozjaśnienia i oczyszczenia kodu programu. Kod zrefaktoryzowany staje się łatwo pielęgnowalny i przez to jest podstawą do dalszego rozwijania na nim aplikacji.

40. Energiczna praca Większa ilość godzin w pracy nie zawsze przekłada się na lepszą efektywność, wręcz przeciwnie. Pracownicy nie powinni pracować powyżej 8h dziennie. Nie powinni też zabierać pracy do domu, gdyż może to doprowadzić do przemęczenia i wypalenia pracownika, co jest szkodą zarówno dla nie go, jak i dla projektu.

41. Wspólne środowisko pracy Zespół powinien znajdować się cały w jednym pomieszczeniu najlepiej również z kierownictwem tak, aby nie było problemu z komunikowaniem się. Praca w grupie zazwyczaj jest wydajniejsza - zwłaszcza gdy jakiś programista ma deadlock...

42. Programowanie w parach Kontrowersyjne, ale płyną z niego korzyści:- przy poznawaniu nowych technologii nauka w parach idzie szybciej- lepsza skuteczność wyłapywania błędów - powstający kod jest jakościowo lepszy - programiści uczą się od siebie nawzajem i mają lepszy kontakt

43. Programowanie w parach ma także wadę - wydajność liczona ilością powstałego kodu nie wzrasta dwukrotnie

44. Testy jednostkowe Testy jednostkowe powinny zostać wykonane dla każdej  klasy i to przed jej implementacją. Dzięki temu będzie można łatwo i szybko wykrywać bugi podczas tworzenia klasy. Poza tym, test jasno określa i skupia uwagę programisty na tych rzeczach które powinny zostać zrobione.Każdy partia kodu musi przejść testy zanim zostanie upubliczniona. Zaś gdy znajdziemy nowy błąd musi powstać nowy test.

45. User Stories User Stories są to opowieści pisane przez użytkownika, na temat rzeczy które chciałby, aby system dlań wykonywał. User Stories są zorientowane na potrzeby użytkownika i nie ma w nich szczegółów funkcjonalnych. Używa się ich przy planowaniu, tworzeniu testów a także implementacji.

46. Iteracyjne poprawianie Iteracyjność w XP przejawia się w planowaniu, projektowaniu oraz implementacji. Na początku nigdy nie uda nam się przewidzieć wszystkiego dlatego budujemy prosty prototyp a później go udoskonalamy w każdej iteracji pokazując go klientowi, dodając nowe funkcjonalności oraz poprawiając błędy.

47. Karty CRC Karty CRC są praktycznym i tanim narzędziem do "wieloosobowego" modelowania systemu. Ich niewielkie rozmiary powodują, że zarówno odpowiedzialność danej klasy jak i powiązania z innymi są nieduże. Jak widać ta metoda pomija strukturę klasy (czyli pola i metody) a skupia się na odpowiedzialnościach i współpracy, dzięki czemu łatwiej jest modelować, gdyż pracujemy za pomocą bardziej potocznego języka - który jak wiadomo zorientowany jest na skuteczność przekazu.

48. Ten slajd to tylko po to by łagodnie przejść do końca prezentacji...

49. Linki i źródła zarazem: http://www.truesolutions.pl/blog/ - 6 częściowy, ciekawy artykuł Jacka o nieznanym nazwisku. http://art.webesteem.pl/10/zp_3.php -bardziej techniczny i powierzchowny artykuł o XP.http://www.extremeprogramming.org - strona "domowa" XP.Wszystkie użyte w prezentacji grafiki zostały zlokalizowane i poprane ze strony Google grafika.

50. FIN