{"id":8955,"date":"2020-04-02T09:42:06","date_gmt":"2020-04-02T07:42:06","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=8955"},"modified":"2023-10-18T09:48:39","modified_gmt":"2023-10-18T07:48:39","slug":"beton-wylewany-jest-tylko-jeden-raz-czyli-po-co-nam-dokumentacja-techniczna","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/beton-wylewany-jest-tylko-jeden-raz-czyli-po-co-nam-dokumentacja-techniczna\/","title":{"rendered":"Beton wylewany jest tylko jeden raz, czyli po co nam dokumentacja techniczna?"},"content":{"rendered":"\n<p><span class=\"fabric-editor-annotation\">Projekty <\/span>z zakresu szeroko poj\u0119tej <span class=\"fabric-editor-annotation\">architektury <\/span>posiadaj\u0105 bardzo obszern\u0105 dokumentacj\u0119. Zasadniczo mo\u017cna doj\u015b\u0107 do wniosku, \u017ce produktem przy tych projektach w istocie jest dokumentacja: dziesi\u0105tki opis\u00f3w, rysunk\u00f3w, kart technicznych, specyfikacji, tabel i uzgodnie\u0144 i najlepiej w 5 lub 6 egzemplarzach. <\/p>\n\n\n\n<p>Mia\u0142am okazj\u0119 pracowa\u0107 przy projekcie, kt\u00f3rego dokumentacja techniczna, po wydrukowaniu, zajmowa\u0142a ca\u0142y baga\u017cnik samochodu typu kombi. I ca\u0142e jego tylne siedzenie. I jeszcze kolana pasa\u017cera. Ilo\u015b\u0107 papieru zu\u017cytego do wydrukowania tej dokumentacji przestali\u015bmy liczy\u0107 w ryzach papieru, a zacz\u0119li\u015bmy liczy\u0107 w kilometrach. Ten konkretny projekt nie by\u0142 odosobnionym przypadkiem, je\u015bli chodzi o obszerno\u015b\u0107 dokumentacji. Przy <span class=\"fabric-editor-annotation\">projektach <\/span>architektonicznych dokumentacja techniczna jest wielotomowa, rozleg\u0142a i szczeg\u00f3\u0142owa. Dlaczego? Ujmijmy to tak: ze wzgl\u0119du na deployment. Jest zawsze tylko jeden. Zawsze od razu na \u015brodowisko produkcyjne. Poniewa\u017c beton leje si\u0119 tylko jeden raz. Je\u015bli si\u0119 pomylisz, wydarz\u0105 si\u0119 na pewno dwie rzeczy \u2013 kto\u015b straci du\u017co pieni\u0119dzy, a kto\u015b inny straci prac\u0119. Zazwyczaj jedn\u0105 z os\u00f3b jest projektant. Przy odrobinie szcz\u0119\u015bcia przytrafi mu si\u0119 tylko jedna ze wspomnianych rzeczy.<\/p>\n\n\n\n<p>Praca dewelopera oprogramowania nie r\u00f3\u017cni si\u0119 bardzo od pracy projektanta. Inne s\u0105 klocki, z kt\u00f3rych buduj\u0105 oni swoje rozwi\u0105zania, inny nacisk jest k\u0142adziony na poszczeg\u00f3lne elementy pracy, ale problemy s\u0105 bardzo podobne. Podobnie jak efekt ko\u0144cowy \u2013 ma \u201edzia\u0142a\u0107\u201d. Tworzenie oprogramowania jest jednak procesem du\u017co bardziej elastycznym ni\u017c budowa obiekt\u00f3w architektonicznych.<\/p>\n\n\n\n<p><span class=\"fabric-editor-annotation\">Zapytaj deweloper\u00f3w<\/span>, jakie czynno\u015bci s\u0105 przez nich najmniej lubiane. Konieczno\u015b\u0107 pisania dokumentacji na pewno znajdzie si\u0119 wysoko na li\u015bcie zada\u0144, kt\u00f3rych unikaj\u0105. W ko\u0144cu ta praca nie jest tw\u00f3rcza, nie wp\u0142ywa na realne dzia\u0142anie oprogramowania. Dokumentacji nikt nie przeczyta, bo po co szuka\u0107 odpowiedzi w dokumentacji skoro \u0142atwiej zada\u0107 pytanie zespo\u0142owi.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Agile a dokumentacja &#8211; czyli czy mo\u017cemy pomin\u0105\u0107 ten punkt?<\/h2>\n\n\n\n<p>Kiedy organizacja postanawia przej\u015b\u0107 transformacj\u0119 i zaimplementowa\u0107 podej\u015bcie <span class=\"fabric-editor-annotation\">Agile <\/span>cz\u0119sto jest to kojarzone z brakiem konieczno\u015bci pisania dokumentacji. Wreszcie mo\u017cna zacz\u0105\u0107 kodowa\u0107 zamiast opisywa\u0107 przysz\u0142\u0105 prac\u0119 i tworzy\u0107 stosy dokument\u00f3w, kt\u00f3rych nikt nigdy nie przeczyta. Sk\u0105d takie podej\u015bcie? Pierwszym co nasuwa si\u0119 na my\u015bl jest jedno z twierdze\u0144 z Manifestu Agile:<\/p>\n\n\n\n<p>\u201cW wyniku naszej pracy, zacz\u0119li\u015bmy bardziej ceni\u0107 dzia\u0142aj\u0105ce oprogramowanie od szczeg\u00f3\u0142owej dokumentacji\u201d.<\/p>\n\n\n\n<p>Ci\u0119\u017cko nie zgodzi\u0107 si\u0119 ze stwierdzeniem, \u017ce produkt jest bardziej warto\u015bciowy ni\u017c jego opis. Ka\u017cdy klient oczekuje oprogramowania, kt\u00f3re b\u0119dzie odpowiedzi\u0105 na jego potrzeby, pomo\u017ce mu osi\u0105gn\u0105\u0107 za\u0142o\u017cone cele <span class=\"fabric-editor-annotation\">a<\/span> w d\u0142u\u017cszej perspektywie &#8211; rozwin\u0105\u0107 biznes. Cz\u0119stym zarzutem kierowanym w stron\u0119 metodyk zwinnych jest pisanie dokumentacji pobie\u017cnie, b\u0105d\u017a te\u017c ca\u0142kowite jej pomini\u0119cie. W ko\u0144cu skoro mamy dzia\u0142aj\u0105ce oprogramowanie, po co tworzy\u0107 jego szczeg\u00f3\u0142owy opis <em>post factum<\/em>? A je\u015bli pracujemy w podej\u015bciu klasycznym &#8211; skoro zale\u017cy nam na dzia\u0142aj\u0105cym oprogramowaniu, to w jakim celu tworzy\u0107 jego opis, kt\u00f3ry z du\u017c\u0105 doz\u0105 prawdopodobie\u0144stwa, nie b\u0119dzie mia\u0142 wiele wsp\u00f3lnego z efektem ko\u0144cowym? Niestety, takie zrozumienie przytoczonego zdania jest b\u0142\u0119dne.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Produkt, projekt i dokumentacja<\/h2>\n\n\n\n<p>Warto zastanowi\u0107 si\u0119 czym jest projekt, czym produkt a czym dokumentacja. I czy faktycznie te 3 elementy s\u0105 odr\u0119bnymi bytami. Na potrzeby tego artyku\u0142u, za\u0142\u00f3\u017cmy, \u017ce naszym celem jest stworzenie aplikacji mobilnej, s\u0142u\u017c\u0105cej do rezerwacji taks\u00f3wek. B\u0119dziemy odwo\u0142ywa\u0107 si\u0119 do tego przyk\u0142adu p\u00f3\u017aniej.<\/p>\n\n\n\n<p>Projekt jest okre\u015blonym czasowo przedsi\u0119wzi\u0119ciem, w wyniku kt\u00f3rego uzyskujemy now\u0105, unikaln\u0105 warto\u015b\u0107. Przy planowaniu projektu powinni\u015bmy okre\u015bli\u0107 wst\u0119pny zarys produktu, jego celowo\u015b\u0107 i potrzebne zasoby, czyli przygotowa\u0107 si\u0119 do uruchomienia prac <span class=\"fabric-editor-annotation\">projekt<\/span>owych. W naszym przyk\u0142adzie &#8211; chcemy stworzy\u0107 aplikacj\u0119 mobiln\u0105, zatem mo\u017cemy za\u0142o\u017cy\u0107, \u017ce b\u0119dziemy potrzebowa\u0107 zespo\u0142u programist\u00f3w, a tak\u017ce urz\u0105dze\u0144 mobilnych, na kt\u00f3rych sprawdzimy poprawno\u015b\u0107 dzia\u0142ania aplikacji, \u015brodowiska deweloperskiego, testowego, produkcyjnego oraz mechanizm\u00f3w automatyzacji.<\/p>\n\n\n\n<p>Nast\u0119pnie mamy produkt &#8211; czyli okre\u015blone dobro &#8211; w formie fizycznej lub w formie us\u0142ugi, b\u0119d\u0105ce odpowiedzi\u0105 na konkretne zapotrzebowania konsument\u00f3w. W przytoczonym przyk\u0142adzie b\u0119dzie to, dzia\u0142aj\u0105ca zgodnie z wymaganiami, aplikacja mobilna.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Zaczynamy pracowa\u0107 nad dokumentacj\u0105<\/h2>\n\n\n\n<p>Mamy ju\u017c okre\u015blony cel, zasadno\u015b\u0107 i wst\u0119pnie &#8211; zasoby. Teraz nadszed\u0142 czas na zaplanowanie pierwszych prac. Warto zorganizowa\u0107 \u201cStory Jam Session\u201d. Podczas takiego spotkania Product Owner przedstawia wizj\u0119 biznesow\u0105 produktu, nast\u0119pnie ca\u0142y Zesp\u00f3\u0142 Deweloperski pracuje nad dookre\u015bleniem poszczeg\u00f3lnych element\u00f3w, jakie powinien posiada\u0107 produkt. Tego typu spotkanie jest istotne z kilku powod\u00f3w &#8211; po pierwsze pozwala na wypracowanie wizji produktu wsp\u00f3lnej dla wszystkich stron zaanga\u017cowanych w projekt. Ponadto, taka sesja pozwala na wykorzystanie potencja\u0142u Zespo\u0142u Deweloperskiego &#8211; zebranie pomys\u0142\u00f3w, kt\u00f3rych Product Owner nie mia\u0142 mo\u017cliwo\u015bci okre\u015bli\u0107 z racji np. ogranicze\u0144 technicznych. Skonfrontowanie wizji produktu z osobami, kt\u00f3re t\u0119 wizj\u0119 fizycznie b\u0119d\u0105 implementowa\u0107 pozwala cz\u0119sto osi\u0105gn\u0105\u0107 ciekawe i inspiruj\u0105ce rezultaty, kt\u00f3re nie pozostaj\u0105 bez znaczenia dla p\u00f3\u017aniejszej warto\u015bci biznesowej wdra\u017canych rozwi\u0105za\u0144.<\/p>\n\n\n\n<p>Efektem ko\u0144cowym \u201cStory Jam Session\u201d b\u0119dzie wk\u0142ad do stworzenia Product <span class=\"fabric-editor-annotation\">Backlog&#8217;u<\/span>, nad kt\u00f3rym nast\u0119pnie b\u0119dzie pracowa\u0142 Product Owner. Zazwyczaj s\u0105 to User Stories (US) &#8211; jedne dookre\u015blone szczeg\u00f3\u0142owo, inne jako pomys\u0142y do rozwa\u017cenia, cz\u0119\u015b\u0107 mo\u017ce wymaga\u0107 dalszej pracy, poniewa\u017c nie spe\u0142nia Definition of Ready (DoR) &#8211; wi\u0119cej informacji na temat DoR oraz innych termin\u00f3w z zakresu Agile znajdziesz w <a href=\"https:\/\/sii.pl\/blog\/przystepny-slownik-pojec-agile\/?category=zarzadzanie-projektami&amp;tag=agile,dictionary,scrum\">&#8222;Przyst\u0119pnym s\u0142owniku poj\u0119\u0107 Agile&#8221;<\/a> opublikowanym na naszym blogu w styczniu 2020. Popularn\u0105 form\u0105 tworzenia US jest opisanie funkcjonalno\u015bci oprogramowania z perspektywy u\u017cytkownika, przy jednoczesnym okre\u015bleniu jej warto\u015bci biznesowej, wed\u0142ug schematu: <em>Jako \u2026, chc\u0119\u2026, aby\u2026<\/em> . Ta prosta forma cz\u0119sto wystarcza, aby odpowiedzie\u0107 na podstawowe pytanie: CO? Pytanie zadajemy w odniesieniu do zakresu efektu ko\u0144cowego, czyli po spe\u0142nieniu jakich warunk\u00f3w mo\u017cemy stwierdzi\u0107, \u017ce funkcjonalno\u015b\u0107 oprogramowania spe\u0142nia wymagania biznesowe. Odnosz\u0105c si\u0119 do przyk\u0142adowej aplikacji mobilnej do obs\u0142ugi rezerwacji taks\u00f3wek: przyk\u0142adowe pytanie <span class=\"fabric-editor-annotation\">CO? <\/span>mo\u017ce brzmie\u0107:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Jako u\u017cytkownik po uruchomieniu aplikacji w przeci\u0105gu 10 sekund widz\u0119 na ekranie list\u0119 3 taks\u00f3wek najbli\u017cszych mojej lokalizacji, aby m\u00f3c zarezerwowa\u0107 preferowan\u0105.<\/li>\n<\/ul>\n\n\n\n<p>Trudniejsz\u0105 kwesti\u0105 jest odpowied\u017a na pytanie JAK? Z punktu widzenia technologii, co musi zosta\u0107 zrobione lub zaimplementowane, aby spe\u0142ni\u0107 wymaganie b\u0119d\u0105ce odpowiedzi\u0105 na pytanie CO? To jest w\u0142a\u015bciwe miejsce do wykorzystania potencja\u0142u zespo\u0142u deweloperskiego. Dla podanego przyk\u0142adu pytania CO? zadanego powy\u017cej, odpowiedzi\u0105 b\u0119dzie okre\u015blenie JAK? chcemy osi\u0105gn\u0105\u0107 za\u0142o\u017cony cel, np.:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Pobranie danych GPS z urz\u0105dze\u0144 taks\u00f3wek zalogowanych do sieci.<\/li>\n\n\n\n<li>Implementacja bazy X w modelu danych Y przy konfiguracji Z<\/li>\n\n\n\n<li>Wyliczenie odleg\u0142o\u015bci za pomoc\u0105 algorytmu Haversine\u2019a<\/li>\n\n\n\n<li>Sortowanie wynik\u00f3w wzgl\u0119dem najkr\u00f3tszej wyliczonej drogi<\/li>\n\n\n\n<li>Zwr\u00f3cenie pierwszych 3 wynik\u00f3w z sortowanej listy.<\/li>\n<\/ul>\n\n\n\n<p>Dokumentacja techniczna powinna zawiera\u0107 odpowied\u017a na oba pytania: CO? oraz JAK? &#8211; maksymalnie zwi\u0119z\u0142\u0105, tre\u015bciw\u0105 i klarown\u0105, zgodn\u0105 ze s\u0142owami Einstein\u2019a: \u201cJe\u015bli nie potrafisz wyja\u015bni\u0107 czego\u015b prosto, nie rozumiesz tego wystarczaj\u0105co dobrze\u201d.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"fabric-editor-annotation\">Po co nam Definition of Done?<\/span><\/h2>\n\n\n\n<p>Zatrzymajmy si\u0119 na chwil\u0119 przy tworzeniu Definition of Done (DoD). Dobrze sformu\u0142owane i pe\u0142ne nie tylko zapewni nam przejrzysto\u015b\u0107 procesu i wska\u017ce spos\u00f3b rozwoju funkcjonalno\u015bci, ale b\u0119dzie pierwszym wsadem do dokumentacji projektowej. Za\u0142\u00f3\u017cmy dla uproszczenia, \u017ce DoD do ka\u017cdego zadania b\u0119dzie zawiera\u0142a informacj\u0119 o tym:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>KIEDY uznajemy funkcjonalno\u015b\u0107 za wdro\u017con\u0105?<\/li>\n\n\n\n<li>Jakie TESTY powinny zosta\u0107 przeprowadzone?<\/li>\n\n\n\n<li>Na jakim \u015aRODOWISKU funkcjonalno\u015b\u0107 ma dzia\u0142a\u0107?<\/li>\n\n\n\n<li>Czy funkcjonalno\u015b\u0107 zosta\u0142a UDOKUMENTOWANA?<\/li>\n<\/ul>\n\n\n\n<p>Zaznaczmy, \u017ce Definition of Done zawiera opis element\u00f3w jako\u015bciowych i niefunkcjonalnych, dzi\u0119ki czemu mo\u017cliwe jest zapewnienie odpowiedniego formatu dokumentacji niezale\u017cnie od czasu powstania przyrostu. Przyk\u0142adowo dla test\u00f3w: Zesp\u00f3\u0142 Deweloperski okre\u015bla komplet test\u00f3w, jakie powinny zosta\u0107 przeprowadzone. Czy przeprowadzone zostan\u0105 testy wydajno\u015bciowe i funkcjonalne czy tak\u017ce obci\u0105\u017ceniowe? Jakie testy automatyczne i\/lub manualne? Na jakim \u015brodowisku funkcjonalno\u015b\u0107 powinna zosta\u0107 przetestowana i wdro\u017cona na koniec Sprintu? Deweloperskim, testowym czy produkcyjnym? Maj\u0105c okre\u015blone wszystkie te wymagania w DoD wdro\u017cenie nast\u0119puje zgodnie z wcze\u015bniej przyj\u0119tym schematem, co zapewnia uporz\u0105dkowanie prac. Stanowi tak\u017ce wsparcie dla Zespo\u0142u Deweloperskiego przy estymacji User Story, poprzez dookre\u015blony zakres prac nad ka\u017cdym zadaniem.<\/p>\n\n\n\n<p>Pozostaje ostatnia kwestia DoD \u2013 dokumentacja. Co powinna zawiera\u0107? Zasadniczo wszystko to, co zosta\u0142o zawarte ju\u017c w konkretnym zadaniu, widziane przez pryzmat DoD, wraz z okre\u015bleniem zmian jakie zosta\u0142y wprowadzone od Planowania do Review, czyli przez ca\u0142y okres pracy deweloperskiej w Sprincie. Powr\u00f3\u0107my do naszego przyk\u0142adu i rozpatrzmy to w oparciu o pytanie JAK?, odnosz\u0105ce si\u0119 do zadania implementacji bazy danych. Zgodnie z pierwotnym za\u0142o\u017ceniem baza danych mia\u0142a by\u0107 oparta o domy\u015bln\u0105 konfiguracj\u0119 (Z). Jednak w trakcie prac okaza\u0142o si\u0119, \u017ce potrzebna jest wi\u0119ksza wydajno\u015b\u0107 pod k\u0105tem pami\u0119ci, a co za tym idzie &#8211; potrzebna jest inna konfiguracja (W). Taka zmiana mo\u017ce by\u0107 skutkiem wielu kwestii, natomiast zawsze jest wynikow\u0105 pracy dewelopera nad zadaniem. Poza wcze\u015bniej wymienionym CO? oraz JAK? r\u00f3wnie\u017c ten element (czyli zmiana wzgl\u0119dem pierwotnego planu) powinien znale\u017a\u0107 si\u0119 w dokumentacji. Dodatkowo wszystkie elementy, kt\u00f3re pojawi\u0142y si\u0119 w trakcie pracy \u2013 okre\u015blone protoko\u0142y, biblioteki (o ile odbiegaj\u0105 od standardowych rozwi\u0105za\u0144), raporty z test\u00f3w &#8211; s\u0105 tymi elementami, kt\u00f3re mo\u017ce dokumentacja techniczna zawiera\u0107. Opis tych komponent\u00f3w powinien by\u0107 maksymalnie zwi\u0119z\u0142y i tre\u015bciwy &#8211; nie piszemy elaboratu tylko dokumentacj\u0119. Wystarczy, \u017ce okre\u015blimy z jakich bibliotek korzystamy, nie musimy opisywa\u0107 ka\u017cdej linii kodu, kt\u00f3ra si\u0119 do niej odnosi.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Czas na retro!<\/h2>\n\n\n\n<p>Retrospektywa to idealny moment na zrobienie inspekcji pracy wykonanej w trakcie ca\u0142ego Sprintu. Metod przeprowadzania Retrospektywy jest wiele, jednak zawsze warto odpowiedzie\u0107 sobie na pytanie: czy osi\u0105gn\u0119li\u015bmy zamierzony cel? Dobr\u0105 praktyk\u0105 jest przegl\u0105d wykonanej pracy pod k\u0105tem DoD i zadanie sobie podstawowych pyta\u0144 do ka\u017cdej z implementowanych funkcjonalno\u015bci:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Jakie problemy pojawi\u0142y si\u0119 w trakcie pracy nad tym zadaniem?<\/li>\n\n\n\n<li>Czym by\u0142y spowodowane?<\/li>\n\n\n\n<li>Jak rozwi\u0105zali\u015bmy te problemy?<\/li>\n<\/ul>\n\n\n\n<p>Odpowied\u017a na ostatnie pytanie cz\u0119sto mo\u017ce by\u0107 cz\u0119\u015bci\u0105 naszej dokumentacji technicznej. W jaki spos\u00f3b finalnie zaimplementowali\u015bmy funkcjonalno\u015b\u0107? Je\u015bli musieli\u015bmy zmie\u0107 np. konfiguracj\u0119 bazy danych, nie opisujemy ca\u0142ej historii researchu i\/lub dewelopmentu &#8211; wystarczy, \u017ce w dokumentacji okre\u015blimy konfiguracj\u0119 ko\u0144cow\u0105. W tym celu mo\u017cemy doda\u0107 nawet plik konfiguracyjny.<\/p>\n\n\n\n<p>Warto zauwa\u017cy\u0107, \u017ce podej\u015bcie zwinne &#8211; w tym przypadku Scrum, ze wzgl\u0119du na ceremonie jakimi s\u0105 Planowanie oraz Retrospektywa, a tak\u017ce dzi\u0119ki wprowadzeniu Definition of Done, wspiera tworzenie dokumentacji. Dobrze przeprowadzone spotkania, skupione na osi\u0105gni\u0119ciu okre\u015blonego celu nie pomijaj\u0105 tworzenia dokumentacji technicznej, tak naprawd\u0119 wspomagaj\u0105 jej tworzenie.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Czas, czas, czas<\/h2>\n\n\n\n<p>Czy pisanie dokumentacji wymaga czasu? Oczywi\u015bcie, \u017ce tak. Jak dla ka\u017cdego zadania &#8211; potrzeba odpowiedniej ilo\u015bci czasu, aby j\u0105 wytworzy\u0107. Podej\u015bcie zwinne sprzyja pisaniu dokumentacji, poniewa\u017c wymaga niewielkiego nak\u0142adu pracy &#8211; w ilo\u015bci i terminie jakie s\u0105 niezb\u0119dne w danym momencie. Nie wymaga dokumentowania na wyrost, w odniesieniu do User Stories, kt\u00f3re jeszcze nie zosta\u0142y opracowane przez Zesp\u00f3\u0142 Deweloperski (nie zosta\u0142y zamienione w przyrost). Dokumentacja to r\u00f3wnie\u017c element codziennej prac Zespo\u0142u Deweloperskiego, tak jak projektowanie UX, kodowanie czy testowanie. U\u015bwiadomienie sobie tego faktu jest pierwszym (ale bardzo wa\u017cnym!) krokiem na drodze do wytwarzania dokumentacji.<\/p>\n\n\n\n<p>Dokumentacja jest tak\u017ce kluczowym elementem dla zespo\u0142\u00f3w pracuj\u0105cych zdalnie. Minimum informacji, jakie powinna zawiera\u0107, wspomaga zesp\u00f3\u0142 w wykonywaniu codziennych zada\u0144. Tworzy przestrze\u0144, gdzie wszystkie najistotniejsze informacje odno\u015bnie przyrostu s\u0105 zebrane w jednym miejscu. Brak mo\u017cliwo\u015bci zadania pytania osobie siedz\u0105cej obok nas, w jednym pokoju lub budynku sprawia, \u017ce czas uzyskania odpowiedzi znacz\u0105co si\u0119 wyd\u0142u\u017ca. Niestety nawet najlepsze komunikatory nie dor\u00f3wnaj\u0105 rozmowie twarz\u0105 w twarz.<\/p>\n\n\n\n<p>Dokumentacja jest tak\u017ce kluczowym elementem, w kwestii zmian zachodz\u0105cych w samym zespole: w przypadku do\u0142\u0105czenia nowej osoby pomaga w szybkim wdro\u017ceniu jej w realia produktu, a tak\u017ce samego projektu. Je\u015bli natomiast deweloper odchodzi z zespo\u0142u, informacje na temat produktu nie znikaj\u0105 wraz z nim. Wiedza zgromadzona przez poszczeg\u00f3lnych cz\u0142onk\u00f3w zespo\u0142u jest nieoceniona i kluczowa przy rozwoju produktu, dlatego konieczne jest niedopuszczenie do sytuacji, w kt\u00f3rej mo\u017cemy t\u0119 wiedz\u0119 utraci\u0107.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Pami\u0119ciowy back-up<\/h2>\n\n\n\n<p>Dokumentacj\u0119 powinni\u015bmy pisa\u0107 r\u00f3wnie\u017c dla samych siebie. Praca nad niekt\u00f3rymi projektami czasami zajmuje wiele miesi\u0119cy, przy czym mo\u017ce zaj\u015b\u0107 potrzeba zmiany element\u00f3w, kt\u00f3re zosta\u0142y ju\u017c wytworzone i wdro\u017cone. O wiele \u0142atwiej sprawdzi\u0107 jakie algorytmy by\u0142y wykorzystane przy rozwoju danej funkcjonalno\u015bci w dokumentacji ni\u017c przypomina\u0107 sobie wszystkie szczeg\u00f3\u0142y dewelopmentu. Wszystkie u\u017cyte technologie, zmiany i algorytmy dla wszystkich mo\u017cliwych funkcjonalno\u015bci s\u0105 niemo\u017cliwe do zapami\u0119tania, dlatego warto zrobi\u0107 sobie \u201epami\u0119ciowy back-up\u201d w postaci dokumentacji technicznej.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Scrum Master a dokumentacja<\/h2>\n\n\n\n<p>Gdzie w tym procesie jest rola dla Scrum Mastera? Wyzwaniem jest pokierowanie zespo\u0142u w stron\u0119 zrozumienia, gdzie znajduje si\u0119 ich dokumentacja i doprowadzenie do sytuacji, aby zesp\u00f3\u0142 nie skazywa\u0142 swojej pracy na zapomnienie. Zr\u0119by dokumentacji technicznej powstaj\u0105 w trakcie Sprintu, podczas Planowania oraz Refinement\u2019u, gdzie zadania mog\u0105 by\u0107 uszczeg\u00f3\u0142awiane lub zmieniane, jak r\u00f3wnie\u017c w trakcie Retrospektywy. Zadaniem zespo\u0142u jest zebranie tych element\u00f3w w jednym miejscu i wykorzystanie ich jako punktu wej\u015bcia do sporz\u0105dzenia dokumentacji technicznej. Ale to rol\u0105 Scrum Mastera jest u\u015bwiadomienie zespo\u0142owi, \u017ce zrobi\u0142 dokumentacj\u0119 podczas Sprintu. Musz\u0105 tylko zebra\u0107 j\u0105 w jednym miejscu. I nie koniecznie musi to by\u0107 baga\u017cnik samochodu typu kombi. \ud83d\ude42<\/p>\n\n\n<div class=\"kk-star-ratings kksr-auto kksr-align-left kksr-valign-bottom\"\n    data-payload='{&quot;align&quot;:&quot;left&quot;,&quot;id&quot;:&quot;8955&quot;,&quot;slug&quot;:&quot;default&quot;,&quot;valign&quot;:&quot;bottom&quot;,&quot;ignore&quot;:&quot;&quot;,&quot;reference&quot;:&quot;auto&quot;,&quot;class&quot;:&quot;&quot;,&quot;count&quot;:&quot;6&quot;,&quot;legendonly&quot;:&quot;&quot;,&quot;readonly&quot;:&quot;&quot;,&quot;score&quot;:&quot;5&quot;,&quot;starsonly&quot;:&quot;&quot;,&quot;best&quot;:&quot;5&quot;,&quot;gap&quot;:&quot;11&quot;,&quot;greet&quot;:&quot;&quot;,&quot;legend&quot;:&quot;5\\\/5 ( votes: 6)&quot;,&quot;size&quot;:&quot;18&quot;,&quot;title&quot;:&quot;Beton wylewany jest tylko jeden raz, czyli po co nam dokumentacja techniczna?&quot;,&quot;width&quot;:&quot;139.5&quot;,&quot;_legend&quot;:&quot;{score}\\\/{best} ( {votes}: {count})&quot;,&quot;font_factor&quot;:&quot;1.25&quot;}'>\n            \n<div class=\"kksr-stars\">\n    \n<div class=\"kksr-stars-inactive\">\n            <div class=\"kksr-star\" data-star=\"1\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" data-star=\"2\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" data-star=\"3\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" data-star=\"4\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" data-star=\"5\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n    <\/div>\n    \n<div class=\"kksr-stars-active\" style=\"width: 139.5px;\">\n            <div class=\"kksr-star\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n            <div class=\"kksr-star\" style=\"padding-right: 11px\">\n            \n\n<div class=\"kksr-icon\" style=\"width: 18px; height: 18px;\"><\/div>\n        <\/div>\n    <\/div>\n<\/div>\n                \n\n<div class=\"kksr-legend\" style=\"font-size: 14.4px;\">\n            5\/5 ( votes: 6)    <\/div>\n    <\/div>\n","protected":false},"excerpt":{"rendered":"<p>Projekty z zakresu szeroko poj\u0119tej architektury posiadaj\u0105 bardzo obszern\u0105 dokumentacj\u0119. Zasadniczo mo\u017cna doj\u015b\u0107 do wniosku, \u017ce produktem przy tych projektach &hellip; <a class=\"continued-btn\" href=\"https:\/\/sii.pl\/blog\/beton-wylewany-jest-tylko-jeden-raz-czyli-po-co-nam-dokumentacja-techniczna\/\">Continued<\/a><\/p>\n","protected":false},"author":238,"featured_media":9028,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_editorskit_title_hidden":false,"_editorskit_reading_time":0,"_editorskit_is_block_options_detached":false,"_editorskit_block_options_position":"{}","inline_featured_image":false,"footnotes":""},"categories":[1318],"tags":[90,879,889,106,91],"class_list":["post-8955","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-zarzadzanie-projektami","tag-agile","tag-agile-atlassian-competency-center","tag-dokumentacja","tag-it","tag-scrum"],"acf":[],"aioseo_notices":[],"republish_history":[],"featured_media_url":"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2020\/03\/agile-beton.jpg","category_names":["Zarz\u0105dzanie projektami"],"_links":{"self":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts\/8955"}],"collection":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/users\/238"}],"replies":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/comments?post=8955"}],"version-history":[{"count":2,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts\/8955\/revisions"}],"predecessor-version":[{"id":25069,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts\/8955\/revisions\/25069"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/media\/9028"}],"wp:attachment":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/media?parent=8955"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/categories?post=8955"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/tags?post=8955"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}