{"id":122,"date":"2013-03-06T20:00:03","date_gmt":"2013-03-06T19:00:03","guid":{"rendered":"http:\/\/jaceksalacki.pl\/?p=122"},"modified":"2014-06-12T20:23:16","modified_gmt":"2014-06-12T19:23:16","slug":"jaka-metodyke-pan-woli","status":"publish","type":"post","link":"https:\/\/jaceksalacki.pl\/index.php\/2013\/03\/06\/jaka-metodyke-pan-woli\/","title":{"rendered":"Jak\u0105 metodyk\u0119 pan woli?"},"content":{"rendered":"<p>Ostatnio, na pewnej rozmowie, w pewnej wa\u017cnej sprawie, dosta\u0142em takie w\u0142a\u015bnie pytanie: &#8222;A jak\u0105 metodyk\u0119 pan woli, agile czy ci\u0119\u017ck\u0105?&#8221;. Chyba jednak nie udzieli\u0142em oczekiwanej odpowiedzi, bo powiedzia\u0142em mniej-wi\u0119cej: &#8222;a tak\u0105, kt\u00f3ra dzia\u0142a&#8221;. Co prawda, moja wypowied\u017a by\u0142a troch\u0119 d\u0142u\u017csza i troch\u0119 bardziej \u0142agodna, ale sens by\u0142 w\u0142a\u015bnie taki. Dzi\u015b wi\u0119c b\u0119dzie o tym co jest lepsze, agile czy ci\u0119\u017ckie metodyki, a w zasadzie o tym, \u017ce takie por\u00f3wnanie nie ma sensu bez okre\u015blenia kontekstu w kt\u00f3rym dzia\u0142amy.<\/p>\n<p><!--more--><\/p>\n<p>Zacznijmy od tego czym si\u0119 r\u00f3\u017cni\u0105 metodyki? Prosta sprawa &#8211; jedne s\u0105 fajne a drugie nie. Bardziej na serio &#8211; od pewnego czasu bycie agile jest modne, a praca w ci\u0119\u017ckiej metodyce jest passe. Ci kt\u00f3rzy &#8222;robi\u0105&#8221; w Scrumie s\u0105 cool a inni s\u0105 nie cool<sup class='footnote'><a href='#fn-122-1' id='fnref-122-1' onclick='return fdfootnote_show(122)'>1<\/a><\/sup>, nic wi\u0119c dziwnego, \u017ce teraz nikt nie chce RUPa, wszyscy chc\u0105 by\u0107 zwinni. Z drugiej strony s\u0105 grupy, kt\u00f3re z politowaniem patrz\u0105 na tych niezdyscyplinowanych, chaotycznych-elastycznych i dumnie wracaj\u0105 do pisania swoich DTD, BRD, SRD, Plan\u00f3w, AS\u00f3w, Studies i serii innych bardzo wa\u017cnych dokument\u00f3w<sup class='footnote'><a href='#fn-122-2' id='fnref-122-2' onclick='return fdfootnote_show(122)'>2<\/a><\/sup>. W\u0142a\u015bnie: grupy. Tu dochodzimy do jednego z powod\u00f3w od kt\u00f3rych skuteczno\u015b\u0107 dzia\u0142ania metodyki zale\u017cy &#8211; od ludzi i zadania. To czy co\u015b zagra zale\u017cy od tego kto gra. Orkiestra symfoniczna czy muzyk klasyczny nie wyka\u017ce si\u0119 przy metalu (chyba \u017ce jest z Finlandii, ma d\u0142ugie w\u0142osy i nale\u017cy do Apocalyptica).\u00a0 Podobnie, dowolne narz\u0119dzie zadzia\u0142a tylko wtedy, gdy b\u0119dzie dostosowane do swojego u\u017cytkownika: jego umiej\u0119tno\u015bci, cech ale te\u017c problemu: jakie jest zadanie, jakie s\u0105 ograniczenia. Metodyka musi by\u0107 wi\u0119c dostosowana do zespo\u0142u i\u00a0 zadania &#8211; musi si\u0119 zgrywa\u0107 z ich charakterem, podej\u015bciem do pracy, wielko\u015bci\u0105 zespo\u0142u<sup class='footnote'><a href='#fn-122-3' id='fnref-122-3' onclick='return fdfootnote_show(122)'>3<\/a><\/sup>, ograniczeniami i z\u0142o\u017cono\u015bci\u0105 projektu a nawet rozmieszczeniem &#8222;geograficznym&#8221;<sup class='footnote'><a href='#fn-122-4' id='fnref-122-4' onclick='return fdfootnote_show(122)'>4<\/a><\/sup>.<\/p>\n<p><strong>Otoczenie<\/strong><\/p>\n<p>Je\u017celi m\u00f3wimy o zespole, mo\u017cna spojrze\u0107 troch\u0119 szerzej i przyjrze\u0107 si\u0119 tak\u017ce otoczeniu projektu, a w\u0142a\u015bciwie rodzajowi kontraktu mi\u0119dzy zespo\u0142em a klientem, odbiorc\u0105 systemu. Czy pozostaje to bez znaczenia dla przyj\u0119tej metodyki? Zdecydowanie nie, spos\u00f3b wsp\u00f3\u0142pracy mi\u0119dzy wykonawc\u0105 a zamawiaj\u0105cym ma bardzo du\u017ce znaczenie dla przyjmowanej metodyki. Odbiorca, w takiej lub innej formie, ma wp\u0142yw na prac\u0119. Znaczenie ma tu charakter klienta &#8211; kim jest, czym si\u0119 zajmuje &#8211; w skr\u00f3cie: inaczej na wsp\u00f3\u0142prac\u0119 b\u0119dzie patrzy\u0142 i innego rodzaju wsp\u00f3\u0142pracy b\u0119dzie wymaga\u0142 dzia\u0142 techniczny, inaczej dzia\u0142 typu HR, marketing, a ca\u0142kiem inaczej dzia\u0142 zajmuj\u0105cy si\u0119 sprzeda\u017c\u0105. Du\u017cy wp\u0142yw ma tak\u017ce rodzaj powi\u0105zania mi\u0119dzy klientem a wykonawc\u0105- pracuj\u0105c w jednej firmie programista i przysz\u0142y u\u017cytkownik b\u0119d\u0105 raczej d\u0105\u017cyli do tego samego<sup class='footnote'><a href='#fn-122-5' id='fnref-122-5' onclick='return fdfootnote_show(122)'>5<\/a><\/sup>, za\u015b pracuj\u0105c dla r\u00f3\u017cnych instytucji, zamawiaj\u0105cego i dostawcy, cele mog\u0105 by\u0107 r\u00f3\u017cne, dogranie te\u017c mo\u017ce by\u0107 r\u00f3\u017cne.<\/p>\n<p><strong>Technologia<\/strong><\/p>\n<p>Skoro wiemy ju\u017c kto i dla kogo pracuje, skupmy si\u0119 na tym czym pracuje, czyli jakiej u\u017cywamy technologii. Dziwne, nie? Przecie\u017c nie ma znaczenia w czym piszemy, metodyka powinna da\u0107 si\u0119 zastosowa\u0107 tak samo. Jednak po bli\u017cszym przyjrzeniu si\u0119, wida\u0107 \u017ce niekt\u00f3re technologie bardziej nadaj\u0105 si\u0119 do jednego rodzaju <span style=\"text-decoration: underline;\">metodyk<\/span> inne do drugiego. Co prawda, trzymaj\u0105c si\u0119 obecnego programistycznego mainstreamu (java, .net, php), poruszamy si\u0119 w\u015br\u00f3d technologii raczej zwinnych, czyli takich kt\u00f3re \u0142atwo si\u0119 &#8222;wdra\u017caj\u0105&#8221; w metodyk\u0119 agile &#8211; po prostu model programistyczny jest mniej-wi\u0119cej podobny. Mimo podobie\u0144stw mo\u017cna zauwa\u017cy\u0107 spore r\u00f3\u017cnice &#8211; bo tu si\u0119 \u0142atwiej prototypuje, a tam bardzo prosto jest zrobi\u0107 testy jednostkowe. A kiedy uwzgl\u0119dnimy jeszcze dodatkowe technologie bardziej specjalistyczne, takie jak narz\u0119dzia webowe, narz\u0119dzia specjalistyczne (ESB,BPM,BI), robi si\u0119 jeszcze trudniej. Dlaczego warto spojrze\u0107 na technologi\u0119? We\u017amy dla przyk\u0142adu r\u00f3\u017cne railsowe narz\u0119dzia jak Ruby on Rails czy Grails. Zrobienie w nich prototypu jest banalnie proste, szybkie i ma\u0142o kosztowe, po co wi\u0119c zu\u017cywa\u0107 energi\u0119 na rysowanie projekt\u00f3w GUI, analizowanie przep\u0142ywu sterowania, skoro mo\u017cna \u0142atwo zrobi\u0107 wst\u0119pn\u0105 wersj\u0119 i dopracowywa\u0107. Lepiej po\u015bwi\u0119ci\u0107 czas dobremu testowaniu takich aplikacji. Z drugiej strony &#8211; je\u017celi przebudowujemy ca\u0142\u0105 warstw\u0119 integracji to opieranie si\u0119 na <em>user stories<\/em> bez szczeg\u00f3\u0142owego projektu proces\u00f3w, struktur danych, plan\u00f3w awaryjnych i opieraniu si\u0119 na &#8222;zmiennym zakresie&#8221; mo\u017ce doprowadzi\u0107 do ogromu problem\u00f3w.<\/p>\n<p><strong>Rodzaj projektu<\/strong><\/p>\n<p>W ko\u0144cu najwa\u017cniejsze &#8211; co robimy, co ma by\u0107 efektem pracy, w jakie problemy rozwi\u0105zujemy. R\u00f3\u017cnica mi\u0119dzy projektem kolejnego portalu spo\u0142eczno\u015bciowego a systemem realizuj\u0105cym transakcje finansowe online jest dostrzegalna go\u0142ym okiem.\u00a0 W przypadku portalu spo\u0142eczno\u015bciowego w zasadzie ci\u0119\u017cko okre\u015bli\u0107 jaki\u015b proces biznesowy, nie m\u00f3wi\u0105c ju\u017c o \u015bcis\u0142ych detalach wymaga\u0144. Dla systemu transakcyjnego proces biznesowy b\u0119dzie zapewne \u015bci\u015ble zdefiniowany do najdrobniejszego szczeg\u00f3\u0142u jeszcze przed rozpocz\u0119ciem budowy oprogramowania. Jaki rodzaj metodyki do kt\u00f3rego rodzaju projektu pasuje jest raczej oczywiste.<\/p>\n<p>Jeszcze na koniec taki dodatkowy parametr, nazywam go unikalno\u015bci\u0105 projektu. Je\u017celi problem, kt\u00f3ry stoi przed zespo\u0142em jest nowy, zesp\u00f3\u0142 jest \u015bwie\u017cy lub pracuje pierwszy raz na powa\u017cnie w danej technologii to mamy\u00a0 do czynienia z unikalnym projektem. Na drugim ko\u0144cu skali jest zesp\u00f3\u0142 kt\u00f3ry t\u0142ucze seryjnie identyczne, lub bardzo podobne, produkty w tej samej technologii. Poniewa\u017c przy rozpoznaniu, poruszamy si\u0119 troch\u0119 po omacku to warto by\u0107 bardziej zwinnym, a je\u017celi pracujemy przy ta\u015bmie to warto skorzysta\u0107 z poprzednich do\u015bwiadcze\u0144 i si\u0119 troch\u0119 usztywni\u0107.<\/p>\n<p><strong>Podsumowanie<\/strong><\/p>\n<p>Dobra, tyle parametr\u00f3w &#8211; ale jak zdecydowa\u0107 si\u0119 na ich podstawie? Co gdy zesp\u00f3\u0142 luzak\u00f3w pracuje dla klienta zewn\u0119trznego nad twardym projektem, realizowanym w mi\u0119kkiej technologii, robi\u0105c kolejny egzemplarz? Przede wszystkim, pomijaj\u0105c prawdopodobie\u0144stwo takiego zdarzenia &#8211; czy s\u0105 to w\u0142a\u015bciwi ludzie wykonuj\u0105cy odpowiedni\u0105 prac\u0119? Mo\u017ce to nie jest projekt dla tego zespo\u0142u, mo\u017ce lepiej wykorzystaj\u0105 swoje cechy i mo\u017cliwo\u015bci gdzie indziej? Czy technologia zosta\u0142a na pewno dobrana do problemu? Czy spos\u00f3b porozumienia z klientem jest dopasowany do projektu(albo odwrotnie)? To naprawd\u0119 warto rozwa\u017ca\u0107 przed przyst\u0105pieniem do pracy. Je\u017celi jednak wszystkie te przemy\u015blenia zosta\u0142y poczynione i nadal mamy problem z wyborem, to przechodzimy do nast\u0119pnego kroku &#8211; strojenie metodyki. Czyli w zasadzie do z\u0142o\u017cenia w\u0142asnej metodyki.<\/p>\n<p>Tak, wg. mnie \u017cadna metodyka wzi\u0119ta prosto z p\u00f3\u0142ki nie jest odpowiednia. Dostosowanie jej do konkretnego przypadku jest niezb\u0119dne, jednak musi by\u0107 przeprowadzone z g\u0142ow\u0105 i konsekwentnie. To\u00a0 nie mo\u017ce by\u0107 zlepek dowolnie wybranych praktyk i regu\u0142 ale wsp\u00f3\u0142graj\u0105ca razem ca\u0142o\u015b\u0107. M\u00f3wi\u0105c o przypadku mam na my\u015bli nie tylko firm\u0119\/dzia\u0142\/zesp\u00f3\u0142 ale konkretny projekt. Metodyka powinna by\u0107 dopasowana do tego jednego zestawu ludzie+technologia+klient+cel projektu. Oczywi\u015bcie, po kilku wsp\u00f3lnych rozgrywkach zesp\u00f3\u0142 wypracuje szablon metodyki, kt\u00f3ry mi\u0119dzy poszczeg\u00f3lnymi projektami b\u0119dzie r\u00f3\u017cni\u0142 si\u0119 niewiele, najcz\u0119\u015bciej zapewne parametrami, ale nadal nie powinien by\u0107 stosowany bezrefleksyjnie do ka\u017cdego nast\u0119pnego zadania.<\/p>\n<p>Pozosta\u0142 w\u0142a\u015bciwie jeden problem &#8211; czym si\u0119 tak naprawd\u0119 r\u00f3\u017cni\u0105 metodyki, czyli co znaczy zwinne i ci\u0119\u017ckie? To jednak ca\u0142kiem inna historia.<\/p>\n<div class='footnotes' id='footnotes-122'>\n<div class='footnotedivider'><\/div>\n<ol>\n<li id='fn-122-1'> cool &#8211; czy jakie tam jest teraz modne okre\u015blenie na bycie modnym <span class='footnotereverse'><a href='#fnref-122-1'>&#8617;<\/a><\/span><\/li>\n<li id='fn-122-2'> tekst by\u0142 pisany oko\u0142o 2 lat temu &#8211; od tego czasu du\u017co si\u0119 zmieni\u0142o, w zasadzie Scrum ju\u017c kr\u00f3luje, tyle \u017ce jest to niestety jaka\u015b hybryda, mutacja prawdziwych metodyk agile, jednak o tym kiedy\u015b indziej <span class='footnotereverse'><a href='#fnref-122-2'>&#8617;<\/a><\/span><\/li>\n<li id='fn-122-3'> zesp\u00f3\u0142 &#8211; zastanawiali\u015bcie si\u0119 kiedy\u015b kto jest w a kto poza? mo\u017cna poczyni\u0107 ciekawe spostrze\u017cenia <span class='footnotereverse'><a href='#fnref-122-3'>&#8617;<\/a><\/span><\/li>\n<li id='fn-122-4'> a raczej rozmieszczeniem przestrzennym; fajnie si\u0119 pracuje bezpo\u015brednio z \u017cywym u\u017cytkownikiem, ale czasem(cz\u0119sto?) nie ma po prostu takiej mo\u017cliwo\u015bci <span class='footnotereverse'><a href='#fnref-122-4'>&#8617;<\/a><\/span><\/li>\n<li id='fn-122-5'> tak wiem, czysto teoretycznie,\u00a0 bo w praktyce to r\u00f3\u017cnie bywa <span class='footnotereverse'><a href='#fnref-122-5'>&#8617;<\/a><\/span><\/li>\n<\/ol>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Ostatnio, na pewnej rozmowie, w pewnej wa\u017cnej sprawie, dosta\u0142em takie w\u0142a\u015bnie pytanie: &#8222;A jak\u0105 metodyk\u0119 pan woli, agile czy ci\u0119\u017ck\u0105?&#8221;. Chyba jednak nie udzieli\u0142em oczekiwanej odpowiedzi, bo powiedzia\u0142em mniej-wi\u0119cej: &#8222;a tak\u0105, kt\u00f3ra dzia\u0142a&#8221;. Co prawda, moja wypowied\u017a by\u0142a troch\u0119 d\u0142u\u017csza i troch\u0119 bardziej \u0142agodna, ale sens by\u0142 w\u0142a\u015bnie taki. Dzi\u015b wi\u0119c b\u0119dzie o tym co jest lepsze, agile czy ci\u0119\u017ckie metodyki, a w zasadzie o tym, \u017ce takie por\u00f3wnanie nie ma sensu bez okre\u015blenia kontekstu w kt\u00f3rym dzia\u0142amy.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,13,3],"tags":[14,15],"class_list":["post-122","post","type-post","status-publish","format-standard","hentry","category-a-gdzie-my-wlasciwie-jestesmy","category-metodyki","category-programowanie","tag-agile","tag-rup"],"_links":{"self":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/122","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/comments?post=122"}],"version-history":[{"count":34,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/122\/revisions"}],"predecessor-version":[{"id":404,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/122\/revisions\/404"}],"wp:attachment":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/media?parent=122"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/categories?post=122"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/tags?post=122"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}