Jak wiemy metodyki zwinne daj\u0105 mo\u017cliwo\u015b\u0107 prowadzenia projektu w r\u00f3\u017cnorodny spos\u00f3b. Istnieje kilka \u015bci\u015ble okre\u015blonych zasad a ca\u0142a reszta to wewn\u0119trzne za\u0142o\u017cenia oraz kompromisy.<\/p>\n\n\n\n
Jako przyk\u0142adem pos\u0142u\u017c\u0119 si\u0119 metodyk\u0105 SCRUM oraz sposobem, w jaki dzieli ona projekt na kolejne etapy. Zasadniczo s\u0105 to trwaj\u0105ce 2-4 tygodni sprinty. Na pocz\u0105tku ka\u017cdego z nich organizowane jest spotkanie maj\u0105ce na celu ustalenie zakresu tego sprintu a na jego koniec nast\u0119puje podsumowanie wykonanej pracy oraz analiza ewentualnych problem\u00f3w, jakie si\u0119 pojawi\u0142y. Ponadto, ka\u017cdy sprint powinien dostarczy\u0107 dzia\u0142aj\u0105cy produkt, kt\u00f3ry mo\u017cemy wdro\u017cy\u0107 na produkcj\u0119.<\/p>\n\n\n\n
Reszta to za\u0142o\u017cenia wynikaj\u0105ce ze specyfiki projektu oraz wewn\u0119trznych, jak i zewn\u0119trznych obostrze\u0144.<\/p>\n\n\n\n
Na przyk\u0142ad …<\/p>\n\n\n\n
Za\u0142\u00f3\u017cmy, \u017ce nasz aktualny projekt operuje na wra\u017cliwych danych finansowych, a przez to proces weryfikacji oraz sprawdzania ka\u017cdej nowej wersji aplikacji jest niezwykle czasoch\u0142onny. Aby zoptymalizowa\u0107 czas potrzebny na przygotowanie dokumentacji potrzebnej do wdro\u017cenia nowej wersji, grupujemy sprinty w p\u00f3\u0142roczne wydania.<\/p>\n\n\n\n
Innym przyk\u0142adem jest uzgodnienie z biznesem stanu wymagania, w kt\u00f3rym mo\u017ce ono by\u0107 oszacowane przez zesp\u00f3\u0142 programist\u00f3w oraz tester\u00f3w. Aby by\u0142o to mo\u017cliwe, wymaganie powinno by\u0107 dobrze rozumiane przez wszystkich zainteresowanych. W przypadku, gdy kto\u015b ma jakiekolwiek w\u0105tpliwo\u015bci lub pytania, powinny one by\u0107 wyja\u015bnione. Dopiero wtedy mo\u017cemy w\u0142\u0105czy\u0107 wymaganie do kolejnych sprint\u00f3w.<\/p>\n\n\n\n
Bior\u0105c pod uwag\u0119 powy\u017csze ustalenia mo\u017cemy okre\u015bla\u0107 moment, kiedy mo\u017cliwa b\u0119dzie implementacja kolejnych wymaga\u0144 w aplikacji z dok\u0142adno\u015bci\u0105 do jednego sprintu.<\/p>\n\n\n\n
W projekcie, w kt\u00f3rym uczestnicz\u0119 w\u0142a\u015bnie zosta\u0142a wydana kolejna wersja. Spotykamy si\u0119 wraz z testerami, biznesem oraz klientem ko\u0144cowym na tygodniowe podsumowanie, aby zweryfikowa\u0107 prace nad ostatni\u0105 wersj\u0105 oraz przedstawi\u0107 plany na najbli\u017csz\u0105 wersj\u0119. Jeden z dni przeznaczony jest na om\u00f3wienie wymaga\u0144 przygotowanych ju\u017c na nast\u0119pn\u0105 wersj\u0119. W\u015br\u00f3d nich znalaz\u0142 si\u0119 zestaw wymaga\u0144 opisuj\u0105cych importowanie danych z plik\u00f3w.<\/p>\n\n\n\n
Do wymaga\u0144 by\u0142o sporo zastrze\u017ce\u0144 oraz w\u0105tpliwo\u015bci. Po wsp\u00f3lnym przeanalizowaniu pojawi\u0142o si\u0119 jeszcze wi\u0119cej niejasno\u015bci. Mieli\u015bmy wra\u017cenie, \u017ce przygotowujemy si\u0119 do estymacji wymaga\u0144, kt\u00f3re s\u0105 jeszcze wersj\u0105 robocz\u0105.<\/p>\n\n\n\n
Podczas sesji uzupe\u0142niania estymat dla wymaga\u0144 otrzymali\u015bmy zaktualizowany zestaw wymaga\u0144, kt\u00f3re r\u00f3\u017cni\u0142y si\u0119 one znacz\u0105co od ich poprzedniej wersji. De facto \u017cadna z wersji wymaga\u0144 nie spe\u0142nia\u0142a przyj\u0119tych w projekcie za\u0142o\u017ce\u0144 odno\u015bnie stanu wymagania.<\/p>\n\n\n\n
Mo\u017cna si\u0119 domy\u015ble\u0107, jak projekt si\u0119 potoczy\u0142. Funkcjonalno\u015b\u0107 by\u0142a krytyczna dla nadchodz\u0105cej wersji, wi\u0119c zosta\u0142a oddana. Sta\u0142o si\u0119 to jednak kosztem bardzo ci\u0119\u017ckiej pracy zespo\u0142u i wielu nerw\u00f3w.<\/p>\n\n\n\n
Jako wniosek mo\u017cna by stwierdzi\u0107, \u017ce trzymanie si\u0119 przyj\u0119tych w projekcie za\u0142o\u017ce\u0144, o ile oczywi\u015bcie s\u0105 w\u0142a\u015bciwe, pozwala p\u0142ynnie go realizowa\u0107 i osi\u0105ga\u0107 sukcesy wsp\u00f3ln\u0105 prac\u0105 bez po\u015bwi\u0119ce\u0144 z jednej ze stron bior\u0105cych udzia\u0142 w projekcie,<\/p>\n\n\n