{"id":141,"date":"2014-04-24T21:10:36","date_gmt":"2014-04-24T21:10:36","guid":{"rendered":"http:\/\/ijbd.eu\/?p=141"},"modified":"2014-04-30T09:42:35","modified_gmt":"2014-04-30T09:42:35","slug":"czy-agile-dziala-relacja-z-seminarium-pmi","status":"publish","type":"post","link":"https:\/\/ijbd.eu\/?p=141","title":{"rendered":"Agile (Scrum) w du\u017cej organizacji"},"content":{"rendered":"<p>Dnia 16 kwietnia 2014 mia\u0142em przyjemno\u015b\u0107 uczestniczy\u0107 w <a title=\"Seminarium PMI Oddzia\u0142 Warszawa - 16.04.2014 - Czy Agile dzia\u0142a ? - Cezary Zieniewicz\" href=\"http:\/\/pmi.org.pl\/index.php\/aktulanosci-warszawa\/859-seminarium-pmi-oddzial-warszawa-16-04-2014-czy-agile-dziala-cezary-zieniewicz\">seminarium<\/a> organizowanym przez Warszawski oddzia\u0142 PMI, kt\u00f3rego tematem by\u0142y praktyczne do\u015bwiadczenia du\u017cej organizacji w zwinnym rozwoju oprogramowania. Oprogramowanie tworzono w metodyce <a href=\"http:\/\/en.wikipedia.org\/wiki\/Scrum_%28software_development%29\">Scrum<\/a>. Seminarium prowadzi\u0142 <a href=\"https:\/\/www.linkedin.com\/pub\/cezary-zieniewicz\/b\/5a8\/464\">Cezary Zieniewicz<\/a>\u00a0Scrum Master wspomagaj\u0105cy swoj\u0105 sztuk\u0105 centrum rozwoju aplikacji NSN &#8211; Nokia Solutions and Networks (NSN) we Wroc\u0142awiu.<!--more--><\/p>\n<p>Wroc\u0142awskie centrum NSN specjalizuje si\u0119 w rozwoju oprogramowania dla infrastruktury sieci kom\u00f3rkowej (np. BTS). Jest to produkt, kt\u00f3rego opr\u00f3cz in\u017cynier\u00f3w zajmuj\u0105cych si\u0119 budow\u0105 i obs\u0142ug\u0105 sieci kom\u00f3rkowych nikt nie ogl\u0105da ale absolutnie wszyscy oczekuj\u0105, \u017ce b\u0119dzie dzia\u0142a\u0142 perfekcyjnie.<\/p>\n<p><strong>Dobre narz\u0119dzie to popularne narz\u0119dzie<\/strong><\/p>\n<p>Seminarium zacz\u0119\u0142o si\u0119 od prezentacji narz\u0119dzi u\u017cywanych w procesie budowy oprogramowania. Wyb\u00f3r dobrych narz\u0119dzi wspieraj\u0105cych rozw\u00f3j oprogramowania ma podstawowe znaczenie, zw\u0142aszcza w metodykach zwinnych kiedy, kiedy \u0142atwo sprowokowa\u0107 kontestacj\u0119 i sprzeciw narzucaj\u0105c narz\u0119dzie niepowa\u017cane. Dlatego dobre narz\u0119dzie to popularne narz\u0119dzie. Rozwi\u0105zania egzotyczne poci\u0105gaj\u0105 za sob\u0105 dodatkowe koszty szkolenia. Tworzenie w\u0142asnych rozwi\u0105za\u0144 to tak\u017ce \u015blepy zau\u0142ek. Grupa tw\u00f3rc\u00f3w &#8211; entuzjast\u00f3w jest zwykle ma\u0142a i nara\u017cona na ryzyko utraty krytycznych zasob\u00f3w, ludzie odchodz\u0105 do innych organizacji lub innych zada\u0144. W\u015br\u00f3d stosowanych narz\u0119dzi wymieniono:<\/p>\n<ul>\n<li><a href=\"http:\/\/en.wikipedia.org\/wiki\/Jenkins_%28software%29\">Jenkins<\/a> &#8211; automatyczne budowanie wersji oprogramowania<\/li>\n<li><a href=\"http:\/\/code.google.com\/p\/googletest\/wiki\/Primer\">googletest<\/a> &#8211; narz\u0119dzie do test\u00f3w<\/li>\n<li><a href=\"http:\/\/en.wikipedia.org\/wiki\/Apache_Subversion\">SVN<\/a> &#8211; Apache Subversion<\/li>\n<li><a href=\"http:\/\/en.wikipedia.org\/wiki\/Crucible_%28software%29\">Crucible<\/a> &#8211; kontrola jako\u015bci kodu<\/li>\n<li><a href=\"http:\/\/www-03.ibm.com\/software\/products\/en\/ratidoorfami\">DOORS<\/a> &#8211; oprogramowanie IBM do zarz\u0105dzania wymaganiami<\/li>\n<\/ul>\n<p>Wyb\u00f3r narz\u0119dzi jest procesem ci\u0105g\u0142ym. Przez pewien czas centrum u\u017cywa\u0142o IBM Rhapsody, jednak to narz\u0119dzie\u00a0 nie sprawdzi\u0142o si\u0119. Kod tworzony na podstawie rysunku (diagramu funkcjonalno\u015bci) by\u0142 bardzo trudny do zrozumienia przez cz\u0142owieka, co utrudnia\u0142o testy. Mo\u017cliwo\u015bci tworzenia test\u00f3w z rysunku za\u015b nie by\u0142o. Poniewa\u017c testy automatycznie tworzonego kodu by\u0142y koszmarem, zdecydowano si\u0119 na odstawienie narz\u0119dzia. Spowodowa\u0142o to redukcj\u0119 rozmiaru kodu o 50% i przy\u015bpieszy\u0142o cykl rozwoju. Jak wida\u0107 automatyzacja nie zawsze prowadzi do spadku koszt\u00f3w.<\/p>\n<p><strong>Zesp\u00f3\u0142 czyli ludzie przed procesami<\/strong><\/p>\n<p>Organizacja, kt\u00f3ra chce wdro\u017cy\u0107 zwinny rozw\u00f3j oprogramowania musi dba\u0107 o ludzi, bo w g\u0142owach ludzi jest pami\u0119\u0107 organizacji. Rotacja zespo\u0142u szkodzi szybko\u015bci i jako\u015bci produkcji oprogramowania. Nie na darmo pierwsza zasada <a title=\"Manifesto for Agile Software Development\" href=\"http:\/\/agilemanifesto.org\/\">Agile Manifesto<\/a> to &#8220;Individuals and interactions over processes and tools&#8221;. Scrum to w\u0142adza zespo\u0142u nad problemem. Zesp\u00f3\u0142 musi by\u0107 kompetentny i mie\u0107 warunki do pracy. Zesp\u00f3\u0142 musi mie\u0107 te\u017c widoki na sukces, bo bez niego popada w zgorzknienie co dramatycznie obni\u017ca wydajno\u015b\u0107 pracy. Tworzenie zespo\u0142u i dob\u00f3r jego cz\u0142onk\u00f3w jest krytyczne dla ostatecznego sukcesu. Zesp\u00f3l tworzy resource manager on dobiera ludzi i odpowiada za sprawdzenie ich kompetencji. Zesp\u00f3\u0142 nie mo\u017ce by\u0107 ani za ma\u0142y ani za du\u017cy, w centrum NSN przyj\u0119to, \u017ce mo\u017ce on liczy\u0107 od 5 do 9 programist\u00f3w, optymalna wielko\u015b\u0107 to 6-7.<\/p>\n<p>Dobry zesp\u00f3\u0142 ma stabiln\u0105 szybko\u015b\u0107 pracy i jest przewidywalny. Oczywi\u015bcie s\u0105 te\u017c zespo\u0142y z\u0142e, kt\u00f3re nie dowo\u017c\u0105 wynik\u00f3w. Naprawa z\u0142ych zespo\u0142\u00f3w jest zadaniem resource manager\u00f3w. Mog\u0105 oni wymienia\u0107 poszczeg\u00f3lnych cz\u0142onk\u00f3w zespo\u0142\u00f3w w ramach oceny okresowej lub miesza\u0107 z\u0142e zespo\u0142y z dobrymi. To drugie oczywi\u015bcie niesie ze sob\u0105 ryzyko stworzenia dw\u00f3ch z\u0142ych lub dw\u00f3ch dobrych zespo\u0142\u00f3w.<\/p>\n<p>Agile powoduje odkorkowanie inicjatywy. Ujawniaj\u0105 si\u0119 jednostki kompetentne i kreatywne, kt\u00f3re dzi\u0119ki samoorganizacji potrafi\u0105 osi\u0105gn\u0105\u0107 doskona\u0142e wyniki. Warunkiem jest przekazanie cz\u0119\u015bci w\u0142adzy w r\u0119ce programist\u00f3w. Oczywi\u015bcie je\u017celi kompetencje cz\u0142onk\u00f3w zespo\u0142u s\u0105 niskie wprowadzenie metodyki Agile ich nie zwi\u0119kszy. Mo\u017cemy nawet osi\u0105gn\u0105\u0107 gorszy ni\u017c przy klasycznym zarz\u0105dzaniu\u00a0 rezultat. Scrum w s\u0142abym zespole nie dzia\u0142a i stanowi zagro\u017cenie dla organizacji, pasywny zesp\u00f3\u0142 trzeba wzmocni\u0107 lub zarz\u0105dza\u0107 nim w inny spos\u00f3b. Scrum to zabawa dla ambitnych, kt\u00f3rym daje mo\u017cliwo\u015bci wykazania si\u0119.<\/p>\n<p><strong>Odpowiedzialno\u015b\u0107 za bud\u017cet<\/strong><\/p>\n<p>Scrum odwraca hierarchi\u0119, mamy X ludzi ile zrobi\u0105 zale\u017cy od tego jak dobrzy s\u0105 i jak dobrze pracuj\u0105. Zesp\u00f3\u0142 nie ma narzuconych odg\u00f3rnie norm wydajno\u015bciowych, jego istnienie jest sta\u0142ym kosztem, warunkiem koniecznym lecz nie dostatecznym dla stworzenia warto\u015bci. U\u017cyteczno\u015b\u0107 pracy zespo\u0142u dla organizacji w olbrzymim stopniu zale\u017cy od Product Ownera, kt\u00f3ry okre\u015bla jak ma wygl\u0105da\u0107 produkt i potrafi pozna\u0107 i przekaza\u0107 zespo\u0142owi w jakim stopniu kolejne iteracje produktu spe\u0142niaj\u0105 jego (i organizacji) oczekiwania. Mamy tu do czynienia z ci\u0105giem prototyp\u00f3w, kt\u00f3re w ka\u017cdej kolejnej iteracji zbli\u017caj\u0105 nas do celu. Nie wyst\u0119puje faza detalicznego planowania i dokumentowania produktu, obowi\u0105zuje zasada &#8220;Working software over comprehensive documentation&#8221;.<\/p>\n<p>Organizacja tworz\u0105ca produkt musi umie\u0107 oceni\u0107 jego warto\u015b\u0107. Koszty wytworzenia szacuje si\u0119 na podstawie pr\u0119dko\u015bci pracy zespo\u0142u, kt\u00f3r\u0105 trzeba zmierzy\u0107. Dobry zesp\u00f3\u0142 jest przewidywalny, po kilku iteracjach do\u015b\u0107 dok\u0142adnie wiadomo w jakim czasie zadanie mo\u017ce by\u0107 wykonane. Kwestionowanie termin\u00f3w podawanych przez zesp\u00f3\u0142 jest ryzykowne. Straty wynikaj\u0105ce z przyj\u0119cia nadmiernie optymistycznych termin\u00f3w s\u0105 wi\u0119ksze ni\u017c koszty dodatkowej pracy i czasu. Scrum jest metodologi\u0105 marchewki, nie kija. Zesp\u00f3\u0142 pracuje najlepiej jak potrafi bo usuwamy problemy ograniczaj\u0105ce jego wydajno\u015b\u0107. Do administracyjnego wyciskania nierealnych termin\u00f3w potrzebna jest inna metodologia, roboczo mo\u017cna nazwa\u0107 j\u0105 Scam&#8230;<\/p>\n<p>Scrum nie by\u0142 stosowany przez biznes, tam stosowano zarz\u0105dzanie przez cele. Oczywi\u015bcie powodowa\u0142o to rozbie\u017cno\u015bci w ocenie tego co jest realne do wykonania. Pocz\u0105tkowe oszacowania na g\u00f3rze i na dole organizacji bardzo si\u0119 r\u00f3\u017cni\u0142y. Potrzebny kompromis osi\u0105gano raczej manewruj\u0105c zakresem prac ni\u017c parciem na zwi\u0119kszenie wydajno\u015bci. Lepiej zrezygnowa\u0107 z nierealnych cel\u00f3w ni\u017c traci\u0107 zasoby na ich osi\u0105gni\u0119cie. Paradoksalnie ci\u015bnienie na wi\u0119ksz\u0105 wydajno\u015b\u0107 mo\u017ce skutkowa\u0107 wi\u0119kszym op\u00f3\u017anieniem, bo ro\u015bnie liczba b\u0142\u0119d\u00f3w i spada motywacja zespo\u0142\u00f3w, kt\u00f3re nie widz\u0105 szans na sukces.<\/p>\n<p><strong>Scrum Master i jego rola<br \/>\n<\/strong><\/p>\n<p>Scrum Master nie jest kierownikiem zespo\u0142u, nie jest tak\u017ce do ko\u0144ca jego cz\u0142onkiem. Jest buforem pomi\u0119dzy zespo\u0142em programist\u00f3w a przeszkodami, kt\u00f3re nie pozwalaj\u0105 na osi\u0105gni\u0119cie pe\u0142nej wydajno\u015bci. Jest s\u0142ug\u0105 i przyw\u00f3dc\u0105 zespo\u0142u w jednej osobie. Jego rola mo\u017ce by\u0107 niewdzi\u0119czna, bo r\u00f3wnie \u0142atwo obci\u0105\u017cy\u0107 go win\u0105 za niepowodzenia zespo\u0142u jak odm\u00f3wi\u0107 udzia\u0142u w sukcesach. Scrum Master odpowiada za przestrzeganie metodyki pracy zespo\u0142u i powinien mie\u0107 wyobra\u017cenie o naturze jego pracy. Brak technicznych kompetencji prowadzi\u0107 mo\u017ce do dogmatycznego trzymania si\u0119 metody a czasem trzeba odpu\u015bci\u0107 Daily Scrum meeting je\u017celi akurat nie ma potrzeby jego przeprowadzenia. Dobry Scrum Master czasem kupi ciastka dla podbudowania nastroju i wie, \u017ce dobrze traktowany zesp\u00f3\u0142 wszystko co dosta\u0142 odda z nawi\u0105zk\u0105. Do\u015bwiadczenia NSN pokaza\u0142y, \u017ce jeden Scrum Master mo\u017ce opiekowa\u0107 si\u0119 dwoma zespo\u0142ami programist\u00f3w, wi\u0119ksze obci\u0105\u017cenie na og\u00f3\u0142 prowadzi do jego przeci\u0105\u017cenia i wypalenia. Lektury polecane dla scrum mastera i nie tylko:<\/p>\n<ul>\n<li><a href=\"http:\/\/www.amazon.com\/Slack-Getting-Burnout-Busywork-Efficiency\/dp\/0767907698\">Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency<\/a> &#8211; Tom DeMarco<\/li>\n<li><a href=\"http:\/\/www.amazon.com\/Scaling-Lean-Agile-Development-Organizational\/dp\/0321480961\">Scaling Lean &amp; Agile Development<\/a> &#8211; Craig Larman &amp; Bas Vodde<\/li>\n<\/ul>\n<p><strong>Product Owner i jego zadania<br \/>\n<\/strong><\/p>\n<p>Product Owner reprezentuje interesy organizacji i jej klienta. W przypadku centrum rozwoju aplikacji jego rola jest trudna, bo nie ma sta\u0142ego kontaktu z klientem ko\u0144cowym, wi\u0119c nie zna odpowiedzi na wszystkie pytania zespo\u0142u. Nie anga\u017cuje si\u0119 te\u017c w bie\u017c\u0105ce prace zespo\u0142u wi\u0119c szybko traci kompetencje techniczne.\u00a0 Prowadzi to do alienacji Product Ownera, bo coraz mniej rozumie zesp\u00f3l a klienta (kt\u00f3ry rezyduje np. w Korei) widuje rzadko i na og\u00f3\u0142 przy okazji t\u0142umaczenia si\u0119 za du\u017ce b\u0142\u0119dy. Specyfika tworzenia oprogramowania do <a href=\"http:\/\/en.wikipedia.org\/wiki\/Base_transceiver_station\">BTS<\/a> wymaga\u0142a du\u017cej wiedzy technicznej Product Ownera, kt\u00f3ry bez niej nie by\u0142 w stanie ani zdefiniowa\u0107 pracy dla zespo\u0142u ani jej odebra\u0107 w trakcie sprint rewiew. Bez aktualnej wiedzy technicznej Product Owner traci\u0142 wiarygodno\u015b\u0107 wobec zespo\u0142u. Pocz\u0105tkowo jeden Product Owner zleca\u0142 prac\u0119 6 zespo\u0142om, ale poniewa\u017c jego obci\u0105\u017cenie by\u0142o zbyt du\u017ce (wed\u0142ug naocznych \u015bwiadk\u00f3w wygl\u0105da\u0142 jak zombie) liczb\u0119 t\u0119 zredukowano do maksymalnie 4.<\/p>\n<p><strong>Scrum w du\u017cych zespo\u0142ach<\/strong><\/p>\n<p>Du\u017cy projekt mo\u017ce wymaga\u0107 zaanga\u017cowania wielu zespo\u0142\u00f3w programist\u00f3w, inaczej nie da si\u0119 go sko\u0144czy\u0107 w rozs\u0105dnym czasie. W konsekwencji trzeba tak\u017ce wprowadzi\u0107 hierarchi\u0119 Product Owner\u00f3w. Potrzebna jest te\u017c osoba, kt\u00f3ra b\u0119dzie mia\u0142a wizj\u0119 ca\u0142ego systemu i wyznacza\u0142a kierunki rozwoju. W centrum NSN tak\u0105 rol\u0119 pe\u0142ni\u0142 Chief Architect.<\/p>\n<p>Du\u017ce projekty realizowane s\u0105 przez zespo\u0142y mi\u0119dzynarodowe, kod tworzony jest w Azji, Europie i Ameryce, produkcja trwa 24 godziny na dob\u0119. Trzeba dba\u0107 o w\u0142a\u015bciw\u0105 komunikacj\u0119, inaczej mo\u017ce kaza\u0107 si\u0119, \u017ce Zespo\u0142y Chi\u0144skie nie wiedz\u0105 czego\u015b, co w Polsce jest oczywiste i vice versa. Dodatkowym problemem s\u0105 r\u00f3\u017cnice kulturowe, wspomniany Chi\u0144czyk nie przyzna si\u0119 do niewiedzy, bo w jego kulturze oznacza to utrat\u0119 twarzy. W mi\u0119dzynarodowym zespole programist\u00f3w trudno jest utrzyma\u0107 jednolit\u0105 jako\u015b\u0107 kodu, czasem jest ona na tyle niska, \u017ce dana ga\u0142\u0105\u017a rozwoju aplikacji przestaje si\u0119 kompilowa\u0107 i trzeba j\u0105 zamkn\u0105\u0107 (zablokowa\u0107 mo\u017cliwo\u015b\u0107 dostarczania nowego kodu) do czasu usuni\u0119cia starych b\u0142\u0119d\u00f3w. W utrzymaniu dyscypliny programist\u00f3w pomaga wizualizacja wynik\u00f3w pracy na monitorach rozmieszczonych w centrach. Wskazuj\u0105 one kt\u00f3re cz\u0119\u015bci kodu maj\u0105 problemy jako\u015bciowe, ile jest b\u0142\u0119d\u00f3w i kt\u00f3ry zesp\u00f3\u0142 jest ich \u017ar\u00f3d\u0142em. Pomimo pocz\u0105tkowo sceptycznego przyj\u0119cia taki spos\u00f3b dyscyplinowania zespo\u0142\u00f3w programist\u00f3w okaza\u0142 si\u0119 bardzo skuteczny motywuj\u0105c odstaj\u0105cych do poprawy jako\u015bci pracy.<\/p>\n<p><strong>Zapewnienie jako\u015bci produktu<\/strong><\/p>\n<p>Produkcja oprogramowania to nieustanne niezadowolenie z efektu. Programista ma tworzy\u0107 kod i testy pisanego kodu. Brak nawyku budowy test\u00f3w unitowych w zespole jest niezawodn\u0105 przepowiedni\u0105 problem\u00f3w z jako\u015bci\u0105 kodu. Scrum Master nie jest kluczowy dla jako\u015bci produktu. Jego zadaniem jest wdro\u017cenie rutyny i nawyku tworzenia test\u00f3w razem z kodem. Dobry zespol dziala dla wlasnej przyjemnosci, kt\u00f3rej cz\u0119\u015bci\u0105 jest tworzenie dobrego produktu. Trzeba przyj\u0105\u0107, \u017ce po\u0142owa czasu zespo\u0142u to kodowanie. Reszt\u0119 zajmuj\u0105 spotkania i testy.<\/p>\n<p>Osobnym zagadnieniem jest dokumentacja kodu. NSN stosowa\u0142o dokumentacj\u0119 dla programist\u00f3w ale zrezygnowano z niej. Powodem by\u0142a permanentna niezgodno\u015b\u0107 dokumentacji z kodem. Zamiast dokumentacji dla programist\u00f3w wprowadzono zasady dokumentowania kodu i rol\u0119 Code Guard, kt\u00f3ry strze\u017ce ich przestrzegania.\u00a0 Uzasadnienie jest proste: Celem dokumentacji kodu jest u\u0142atwienie przej\u0119cia jego rozwoju przez innego programist\u0119 je\u017celi autor jest niedost\u0119pny (np. odszed\u0142 z organizacji). Code Guard jest programist\u0105, kod kt\u00f3ry sprawdza jest dla niego obcy. Je\u017celi jest w stanie go zrozumie\u0107 to znaczy, \u017ce inny programista mo\u017ce przej\u0105\u0107 dalszy rozw\u00f3j sprawdzanego kodu. Taki poziom dokumentacji uznajemy za dostateczny. Working software over comprehensive documentation.<\/p>\n<p><strong>Organizacja pracy zespo\u0142u<\/strong><\/p>\n<p>Zesp\u00f3\u0142 procowa\u0142 w 2 tygodniowych spintach. W wyj\u0105tkowych przypadkach czas sprintu wyd\u0142u\u017cano do 3 tygodni. Obowi\u0105zywa\u0142a zasada, \u017ce zesp\u00f3\u0142, kt\u00f3ry stworzy\u0142 kod usuwa b\u0142\u0119dy w tym kodzie. W zwi\u0105zku z tym zesp\u00f3\u0142 musia\u0142 alokowa\u0107 zasoby do usuwania b\u0142\u0119d\u00f3w, \u015brednio by\u0142y to dwie osoby. Oczywi\u015bcie zasoby alokowano dynamicznie, je\u017celi b\u0142\u0119d\u00f3w nie by\u0142o wszyscy mogli tworzy\u0107 nowy kod. W organizacji stworzono rol\u0119 Inwestygatora, kt\u00f3ry potwierdza\u0142, \u017ce zg\u0142oszony b\u0142\u0105d jest b\u0142\u0119dem kodu, okre\u015bla\u0142 w kt\u00f3rym miejscu wyst\u0119puje i przekazywa\u0142 do odpowiedniego zespo\u0142u programist\u00f3w. B\u0142\u0119dom nadawano priorytety. Najwy\u017cszy priorytet mia\u0142y b\u0142\u0119dy zg\u0142oszone przez klienta.<\/p>\n<p>Istotnym zagadnieniem jest zarz\u0105dzanie wiedz\u0105 w zespole. Nale\u017cy unika\u0107 koncentracji wiedzy w pojedynczych osobach. Teoria Scrum m\u00f3wi o pe\u0142nej wymienno\u015bci cz\u0142onk\u00f3w zespo\u0142u, ale trudno jest to osi\u0105gn\u0105\u0107 w praktyce. Dobrym rozwi\u0105zaniem jest dzielenie wiedzy w parach. Zesp\u00f3\u0142 powinien stanowczo unika\u0107 tworzenia os\u00f3b niezast\u0105pionych. Rol\u0105 Scrum Mastera jest wczesne ostrzeganie przed tak\u0105 sytuacj\u0105. Zesp\u00f3\u0142 musi mie\u0107 rezerwy czasu na rozw\u00f3j. Jako norm\u0119 przyj\u0119to 2 szkolenia zewn\u0119trzne po 3 dni w roku dla ka\u017cdego cz\u0142onka zespo\u0142u. Za planowanie i organizacj\u0119 szkole\u0144 odpowiada resource manager.<\/p>\n<p><strong>Podsumowanie skuteczno\u015bci Scrum<\/strong><\/p>\n<p>Wroc\u0142awskie centrum powsta\u0142o z po\u0142\u0105czenia zespo\u0142\u00f3w Nokii i Siemensa. W organizacji Siemensa obowi\u0105zywa\u0142o podej\u015bcie klasyczne. Wszystko dok\u0142adnie planowano, tworzono bardzo du\u017co papieru. Podej\u015bcie zwinne przysz\u0142o z Finlandii i zdobywa\u0142o uznanie stopniowo. W ci\u0105gu 4 lat z 7 zespo\u0142\u00f3w Scrum zrobilo sie 14. \u015arednia rotacja product owner\u00f3w i scrum master\u00f3w wynosi\u0142a 2 lata. Co ciekawe Scrum sprawdzi\u0142 si\u0119 tak\u017ce jako metoda konkurowania o programist\u00f3w. Credit Suisse otworzy\u0142 we Wroc\u0142awiu centrum produkcji oprogramowania, gdzie u\u017cywano systemu nakazowego do zarz\u0105dzania zespo\u0142em. Nowe centrum podebra\u0142o cz\u0119\u015b\u0107 programist\u00f3w NSN oferuj\u0105c lepsze warunki finansowe. Jednak po jakim\u015b czasie zdolni ludzie wr\u00f3cili. Widocznie wi\u0119ksze pieni\u0105dze nie rekompensowa\u0142y braku w\u0142adzy nad problemem, kt\u00f3r\u0105 dawa\u0142 Scrum i wynikaj\u0105cej z niej przyjemno\u015bci pracy.<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Dnia 16 kwietnia 2014 mia\u0142em przyjemno\u015b\u0107 uczestniczy\u0107 w seminarium organizowanym przez Warszawski oddzia\u0142 PMI, kt\u00f3rego tematem by\u0142y praktyczne do\u015bwiadczenia du\u017cej organizacji w zwinnym rozwoju oprogramowania. Oprogramowanie tworzono w metodyce Scrum. Seminarium prowadzi\u0142 Cezary Zieniewicz\u00a0Scrum Master wspomagaj\u0105cy swoj\u0105 sztuk\u0105 centrum rozwoju aplikacji NSN &#8211; Nokia Solutions and Networks (NSN) we Wroc\u0142awiu.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[5,1],"tags":[],"class_list":["post-141","post","type-post","status-publish","format-standard","hentry","category-relacje","category-uncategorized"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4qwq1-2h","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/posts\/141","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/ijbd.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=141"}],"version-history":[{"count":14,"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/posts\/141\/revisions"}],"predecessor-version":[{"id":157,"href":"https:\/\/ijbd.eu\/index.php?rest_route=\/wp\/v2\/posts\/141\/revisions\/157"}],"wp:attachment":[{"href":"https:\/\/ijbd.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=141"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ijbd.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=141"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ijbd.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=141"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}