WSTĘP

Dlaczego Scrum?

Po raz pierwszy opracowałem metodę Scrum wraz z Kenem Schwaberem dwadzieścia lat temu, jako szybszy, bardziej niezawodny i efektywny sposób tworzenia oprogramowania w branży technicznej. Do tego czasu - a nawet do roku 2005 - większość projektów programistycznych była tworzona metodą kaskadową (Waterfall), w której projekt realizowany w odrębnych etapach posuwał się krok po kroku w kierunku ostatecznej wersji przeznaczonej dla odbiorców lub użytkowników. Proces był powolny, nieprzewidywalny, a często jego wynikiem nie był produkt, który ludzie chcieli lub za który byliby skłonni zapłacić. Opóźnienia o miesiące, czy nawet lata, były w tym procesie powszechne. Początkowe plany kolejnych etapów, projektowane za pomocą wygodnych, szczegółowych wykresów Gantta, dawały kierownictwu poczucie kontrolowania procesu tworzenia - lecz z całą pewnością szybko można było znaleźć się poza harmonogramem lub katastrofalnie przekroczyć budżet.

Aby przezwyciężyć te problemy, w 1993 r. wymyśliłem nową metodę postępowania: Scrum. Nastąpiła radykalna zmiana w stosunku do stosowanej w przeszłości metodologii zarządzania projektem "od ogółu do szczegółu" (top-down). Scrum przypomina raczej ewolucyjne, adaptacyjne i samonaprawiające się systemy. Od czasu powstania struktura Scrum stała się tym sposobem, za pomocą którego branża techniczna tworzy nowe oprogramowanie i produkty. Mimo że metoda odniosła znaczący sukces przy zarządzaniu projektami dotyczącymi oprogramowania i sprzętu w Silicon Valley, pozostała stosunkowo nieznana w ogólnej praktyce biznesowej. Dlatego właśnie napisałem Scrum: aby pokazać i wyjaśnić system zarządzania metodą Scrum biznesmenom spoza świata technologii. W książce tej piszę o początkach Scruma w systemie produkcji Toyoty oraz o zastosowaniu w pętli OODA w lotnictwie bojowym. Omawiam sposób organizowania projektów w oparciu o małe zespoły - i dlaczego jest to tak efektywna metoda pracy. Wyjaśniam, jak szeregować projekty pod względem ważności, jak zorganizować jednotygodniowe lub jednomiesięczne "sprinty", aby nabrać rozpędu i uczynić odpowiedzialną każdą osobę w zespole, jak prowadzić krótkie codzienne spotkania na stojąco, aby mieć na oku to, co zostało zrobione, i problemy, które pojawiają się nieuchronnie. I tłumaczę, że Scrum zawiera w sobie zasadę ciągłego ulepszania i minimalnych realnych produktów, aby natychmiast uzyskać opinię od konsumentów, zamiast czekać, aż projekt zostanie ukończony. Jak pokazano na dalszych stronach książki, stosowaliśmy metodę Scrum, aby budować wszystko - od niedrogich samochodów, spalających 2,35 litra na 100 km[1], po przenoszenie systemów baz danych FBI w XXI wiek.

Zapraszam do dalszej lektury. Myślę, że zobaczysz, jak metoda Scrum może pomóc w transformacji sposobu, w jaki wasza firma pracuje, tworzy, planuje i myśli. Zdecydowanie wierzę, że Scrum pomaga zrewolucjonizować sposób działania biznesu w każdej niemal branży, tak jak to się stało w przypadku innowacji i szybkości pojawienia się na rynku w szerokim wachlarzu nowych firm i ogromnym zakresie nowych produktów rodzących się w Silicon Valley i w świecie technologii.

Dr Jeff Sutherland

PRZEDMOWA DO WYDANIA POLSKIEGO

Informatyka, a w szczególności oprogramowanie, przez ostatnie dekady stała się nieodłączną częścią wszystkiego, co powstaje w naszym świecie. Doświadczamy tego na co dzień w postaci produktów, których funkcjonowanie jest zależne od oprogramowania. Nasze telefony, nasze komputery, nasze zegarki potrafią coraz więcej, ale i nasze lodówki, pralki, ekspresy do kawy, czy chociażby karty kredytowe w portfelu, stają się wygodniejsze w obsłudze, bardziej zaawansowane i - można by rzec - bardziej inteligentne. Zdajemy sobie również sprawę z tego, że produkty, które w swojej ostatecznej postaci nie zawierają elektroniki, powstały lub powstaną z wykorzystaniem zaawansowanych systemów IT.

I do tego wszystkiego niezbędne jest oprogramowanie, co ważniejsze, dobre oprogramowanie. Nasze funkcjonowanie staje się od niego zależne, więc jeśli nie będzie on dobry, to będzie nam w najlepszym wypadku niewygodnie. Lecz w skrajnych sytuacjach może to być niebezpieczne lub nawet śmiertelnie groźnie.

Aby powstał dobry software, musi być spełnionych wiele warunków. Z mojej perspektywy dwa są podstawowe. Chodzi o odpowiedni zespół tworzący dzieło i adekwatny proces wytwórczy. Niby warunki te wydają się oczywiste, ale nadal wyjątkowo często widać, że nie są spełniane i albo powstałe dzieła są niekompletne, albo po prostu miernej jakości, albo czas i środki przekazane na stworzenie produktu właściwego znacznie przekraczają początkowe założenia.

Warunek pierwszy: zespół.

Dobranie właściwych osób, pod kątem ich kompetencji, doświadczenia i predyspozycji interpersonalnych, nie jest zadaniem prostym. W 7N stawiamy na małe elitarne zespoły złożone wyłącznie z doświadczonych ekspertów. Uważamy, że mały zespół ludzi znających się na rzeczy jest w stanie zrealizować dużo więcej niż duża grupa, w której nie wszyscy będą najlepszymi specjalistami, a do tego rozmiar organizacji wpłynie na rozmycie pojęcia wspólnego celu. Dosyć precyzyjnie ten obszar opisują prace i badania Randy'ego Y. Hirokawy. W ramach naszej własnej metodyki budowy zespołów, oprócz wymogów doświadczenia oraz ekspertyzy technologicznej, bardzo duży nacisk kładziemy na sferę interpersonalną poszczególnych członków zespołu. Przeprowadziliśmy wspólnie z ekspertami z zakresu psychologii biznesowej badanie najlepiej funkcjonujących zespołów i osób w nich działających i zbudowaliśmy mapę sześciu kompetencji występujących u każdego z ich członków. Nazywamy je 7N Secret Code. Są to: samokrytycyzm, wysoka efektywność w warunkach stresu, całościowe rozumienie projektów, dyplomacja, otwartość, empatia. Różne osoby posiadają różną mieszankę tych właśnie kompetencji, a zbudowanie dobrego zespołu to odpowiednie ich dobranie oraz wypełnienie wszystkich sześciu wspomnianych obszarów.

Warunek drugi: proces.

Zgodnie z filozofią małych elitarnych zespołów, której jesteśmy wierni od ponad dwudziestu lat, jesteśmy także wierni procesom iteracyjnym, które stawiają na odpowiednio zarządzany dialog i szybkie reagowanie na zmieniające się otoczenie. I tutaj pojawił się Scrum. Wcześniej można było obserwować mniej bądź więcej udane projekty wykorzystujące jego elementy, natomiast dopiero usystematyzowanie metodyki spowodowało rozkwit, a nawet boom, takiego podejścia do produkcji oprogramowania.

I w tym właśnie momencie dochodzimy do sedna, czyli książki, którą szanowny Czytelniku masz właśnie w rękach, napisanej przez jednego ze współtwórców metodyki Scrum - Jeffa Sutherlanda. Na rynku jest wiele rodzimych czy zagranicznych, przetłumaczonych na język polski, pozycji opisujących Scruma. Wierzę, że przeczytanie każdej z nich na pewno poszerzy Twoją wiedzę z zakresu metodyki, pomoże zrozumieć lepiej poszczególne jej elementy.

Scrum. Czyli jak robić dwa razy więcej, dwa razy szybciej ma w sobie coś więcej. Kiedy zostaliśmy zaproszeni do udziału w tym projekcie jako sponsor tłumaczenia, wiedzieliśmy, że to wspaniałe dzieło. Jeff Sutherland w swoich przemówieniach oraz w tej pozycji w niesamowity sposób oddaje cały proces myślowy, który towarzyszy Scrumowi. Nie jest to czysto informacyjna literatura edukacyjna, ale piękna podróż przez metodykę.

Nasze obawy budził fakt, czy wydawcy uda się uzyskać tłumaczenie godne oryginału, które odda ten niesamowity efekt podróży w czasie, nie gubiąc waloru edukacyjnego książki. Miałem jednak okazję zapoznać się z przekładem, więc na zakończenie dodam tylko jedno - nie mogę doczekać się egzemplarza polskiej edycji.

Sebastian Podleśny

7N, Agent for High-End IT Professionals

Senior Vice President Poland & India, Partner

Warszawa, 31 lipca 2015 r.