{"id":989,"date":"2020-05-10T16:22:51","date_gmt":"2020-05-10T16:22:51","guid":{"rendered":"https:\/\/kalkus.dev\/?p=989"},"modified":"2023-08-24T23:18:01","modified_gmt":"2023-08-24T23:18:01","slug":"prawo-brooksa","status":"publish","type":"post","link":"https:\/\/kalkus.dev\/blog\/2020\/05\/10\/prawo-brooksa\/","title":{"rendered":"Prawo Brooksa"},"content":{"rendered":"\n

Estymacja si\u0119 nie uda\u0142a, deadline nas pokona\u0142, nie wyrobimy si\u0119. Manager dorzuca ludzi do projektu, ale okazuje si\u0119 to by\u0107 gaszeniem po\u017caru benzyn\u0105. Poznajcie prawo Brooksa.<\/em><\/h3>\n\n\n\n

Fred Brooks jest jedn\u0105 z najbardziej znanych postaci z dziedziny rozwoju oprogramowania. W Polsce nie wiedzie\u0107 czemu jest stosunkowo nieznany, a szkoda. Brooks zrobi\u0142 w \u017cyciu dwie wielkie rzeczy – solidnie przy\u0142o\u017cy\u0142 si\u0119 do rozwoju produkt\u00f3w IBM, w tym OS\/360 oraz napisa\u0142 ksi\u0105\u017ck\u0119 Mityczny osobomiesi\u0105c. To w\u0142a\u015bnie z niej, a konkretniej z tytu\u0142owego eseju pochodzi prawo nazwane jego nazwiskiem \u2013 prawo Brooksa.<\/p>\n\n\n\n

Prawo Brooksa m\u00f3wi: <\/p>\n\n\n\n

\u201edodawanie ludzi do op\u00f3\u017anionego projektu op\u00f3\u017ania go jeszcze bardziej\u201d<\/p><\/blockquote>\n\n\n\n

Bardzo bym chcia\u0142, by \u015bwiadomo\u015b\u0107 tej regu\u0142y upowszechni\u0142a si\u0119 nad Wis\u0142\u0105, bo oszcz\u0119dzi\u0142oby to wielu programistom i mened\u017cerom zb\u0119dnego stresu…<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Dziewi\u0119\u0107 kobiet nie urodzi dziecka w miesi\u0105c<\/strong><\/h4>\n\n\n\n

W eseju opisuj\u0105cym prawo Brooksa, autor rozr\u00f3\u017cnia zadania na trzy rodzaje:<\/p>\n\n\n\n

  • zadania idealnie podzielne<\/li>
  • zadania niepodzielne<\/li>
  • zadania podzielne, wymagaj\u0105ce komunikacji<\/li><\/ul>\n\n\n\n

    Zadania idealnie podzielne<\/strong><\/h4>\n\n\n\n

    Skr\u0119canie d\u0142ugopis\u00f3w lub zbieranie szparag\u00f3w to przyk\u0142ady zada\u0144 idealnie podzielnych. Dzielimy to, co jest do wykonania na cz\u0119\u015bci i przydzielamy r\u00f3\u017cnym pracownikom. Nie istnieje potrzeba by si\u0119 mi\u0119dzy sob\u0105 komunikowali. Chc\u0105c wykona\u0107 prac\u0119 szybciej mo\u017cemy wys\u0142a\u0107 na pole albo do skr\u0119cania wi\u0119cej ludzi. Wy\u015blemy dwukrotnie wi\u0119cej, dwukrotnie szybciej sko\u0144cz\u0105.<\/p>\n\n\n\n

    Zadania niepodzielne<\/strong><\/h4>\n\n\n\n

    Cho\u0107by\u015bmy do wymiany oleju w samochodzie przydzielili pi\u0119ciu mechanik\u00f3w, to nie zrobi\u0105 tego szybciej. Olej musi sp\u0142yn\u0105\u0107, nowy musi by\u0107 nalany. Nic nie da dodawanie ludzi.<\/p>\n\n\n\n

    Zadania podzielne, wymagaj\u0105ce komunikacji<\/strong><\/h4>\n\n\n\n

    I tu w\u0142a\u015bnie dochodzimy do tworzenia programowania. Wykonanie nowej aplikacji wymaga koordynacji mi\u0119dzy cz\u0142onkami zespo\u0142u. Co wi\u0119cej wymaga r\u00f3wnie\u017c wdro\u017cenia nowych os\u00f3b.<\/p>\n\n\n\n

    Poni\u017csza grafika ilustruje, jak lawinowo ro\u015bnie potencjalna ilo\u015b\u0107 interakcji w zespole w zale\u017cno\u015bci od ilo\u015bci cz\u0142onk\u00f3w. Ka\u017cda interakcja, rozmowa, wymiana wiedzy mi\u0119dzy dwoma osobami kosztuje czas, czas tym cenniejszy im bardziej sp\u00f3\u017aniony jest projekt.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Nowi ludzie w projekcie<\/strong><\/h4>\n\n\n\n

    Najgorsze w prawie Brooksa jest to, \u017ce jest ono sprzeczne z intuicj\u0105. Wydaje si\u0119 bowiem oczywiste, \u017ce je\u015bli jakie\u015b zadanie b\u0119dzie wykonywa\u0142a wi\u0119ksza ilo\u015b\u0107 os\u00f3b to musz\u0105 je sko\u0144czy\u0107 szybciej. W ko\u0144cu projekt to nie jedno, ale wiele zada\u0144. Na tablicy \u201edo zrobienia\u201d s\u0105 r\u00f3\u017cne taski, wi\u0119c wezm\u0105 je i zaczn\u0105 dzia\u0142a\u0107. Co mo\u017ce p\u00f3j\u015b\u0107 nie tak?<\/p>\n\n\n\n

    Wbrew pozorom \u2013 sporo.<\/p>\n\n\n\n

    Przychodz\u0105 nowe osoby. Konfiguruj\u0105 swoje komputery, instaluj\u0105 oprogramowanie, \u015bci\u0105gaj\u0105 kod \u017ar\u00f3d\u0142owy. Niby co\u015b robi\u0105, ale \u017cadnego z tego widocznego efektu przez pierwsze godziny\/dni. Wydali\u015bmy pieni\u0105dze, a nie zyskali\u015bmy jeszcze nic.<\/p>\n\n\n\n

    Wszystko jest technicznie gotowe, nowi mog\u0105 zacz\u0105\u0107 prac\u0119. Musz\u0105 si\u0119 jednak dowiedzie\u0107, co maj\u0105 do zrobienia. Organizuje si\u0119 wi\u0119c spotkania wyja\u015bniaj\u0105ce natur\u0119 projektu. Teraz ju\u017c nie tylko nowe osoby w projekcie nie posuwaj\u0105 pracy do przodu, ale te\u017c dotychczasowi cz\u0142onkowie zespo\u0142u przestali pracowa\u0107 nad tym co kluczowe.<\/p>\n\n\n\n

    Spotkania si\u0119 zako\u0144czy\u0142y. Nowi mniej wi\u0119cej wiedz\u0105, co robi\u0107. Zaczynaj\u0105 prac\u0119. Wydaje si\u0119, \u017ce post\u0119p w ko\u0144cu ruszy z kopyta. Tymczasem wszystkie okresowe spotkania w zespole zacz\u0119\u0142y zajmowa\u0107 wi\u0119cej czasu. Zak\u0142adaj\u0105c, \u017ce pracujemy w scrum \u2013 d\u0142u\u017csze staj\u0105 si\u0119 daily, refinementy, planowanie sprintu i retrospekcja.<\/p>\n\n\n\n

    Wszystko wydaje si\u0119 i\u015b\u0107 do przodu, ale to, czego nie wida\u0107 na pierwszy rzut oka, to nieustanne pytania nowych os\u00f3b do starej cz\u0119\u015bci zespo\u0142u. Nie da si\u0119 r\u00f3wnie\u017c zauwa\u017cy\u0107, \u017ce te pytania przerywaj\u0105c prac\u0119 rujnuj\u0105 ich skupienie. Czasami po kilku minutach rozmowy programista potrzebuje pi\u0119tnastu minut lub p\u00f3\u0142 godziny, by wr\u00f3ci\u0107 do produktywno\u015bci sprzed rozproszenia. Co wi\u0119cej programi\u015bci pracuj\u0105 przecie\u017c nad tymi samymi plikami w zespole. Kiedy by\u0142o ich trzech nie wchodzili sobie za bardzo w drog\u0119. Nagle okazuje si\u0119, \u017ce merge\u2019owanie, scalanie plik\u00f3w po zmianach kolejnych trzech os\u00f3b staje si\u0119 zmor\u0105 i zajmuje du\u017co czasu. Wydajno\u015b\u0107 wszystkich znacz\u0105co spad\u0142a, zadowolenie r\u00f3wnie\u017c, a post\u0119p jest wolniejszy, ni\u017c si\u0119 spodziewali\u015bmy. Dopad\u0142o nas prawo Brooksa.<\/p>\n\n\n\n

    To co, nic nie robi\u0107?<\/strong><\/h4>\n\n\n\n

    Co robi\u0107 w przypadku op\u00f3\u017anionego projektu to oczywi\u015bcie doskona\u0142e pytanie, na kt\u00f3re jak s\u0105dz\u0119 nie da si\u0119 odpowiedzie\u0107 og\u00f3lnie. Nie by\u0142bym na tyle ortodoksyjny, by stwierdzi\u0107, \u017ce na pewno nie mo\u017cna doda\u0107 kolejnej osoby do zespo\u0142u, ale s\u0105dz\u0119, \u017ce warto si\u0119 nad tym dobrze zastanowi\u0107, przemy\u015ble\u0107 ile takich os\u00f3b i na jak d\u0142ugo planujemy dokoptowa\u0107, a tak\u017ce koniecznie trzeba porozmawia\u0107 z zespo\u0142em i zapyta\u0107, jak taki pomys\u0142 im si\u0119 podoba.<\/p>\n\n\n\n

    W wielu przypadkach naprawd\u0119 nie ma sensu dodawa\u0107 ludzi do sp\u00f3\u017anionego projektu. Deadline i tak b\u0119dzie przekroczony, praca zako\u0144czy si\u0119 szybciej, ni\u017c gdyby nie dodawa\u0107 nikogo, a koszt b\u0119dzie niepotrzebnie zwi\u0119kszony.<\/p>\n\n\n\n

    Co jednak bardziej istotne, czasami dodanie ludzi do zespo\u0142u mo\u017ce sko\u0144czy\u0107 si\u0119 autentyczn\u0105 tragedi\u0105. Wtedy prawo Brooksa ujawnia si\u0119 z ca\u0142\u0105 jaskrawo\u015bci\u0105. Je\u015bli termin jest naprawd\u0119 kr\u00f3tki, a ilos\u0107 os\u00f3b ju\u017c oscyluje wok\u00f3\u0142 dziewi\u0119ciu i chcemy dorzuci\u0107 jeszcze czw\u00f3rk\u0119, mo\u017ce si\u0119 okaza\u0107, \u017ce zesp\u00f3\u0142 si\u0119 kompletnie komunikacyjnie zakorkuje i nie tylko nie dostarczy produktu na czas, ale dostarczy zdecydowanie p\u00f3\u017aniej, ni\u017c by\u015bmy si\u0119 spodziewali i to absurdalnie wi\u0119kszym kosztem.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Estymacja si\u0119 nie uda\u0142a, deadline nas pokona\u0142, nie wyrobimy si\u0119. Manager dorzuca ludzi do projektu, ale okazuje si\u0119 to by\u0107 gaszeniem po\u017caru benzyn\u0105. Poznajcie prawo Brooksa. Fred Brooks jest jedn\u0105 z najbardziej znanych postaci z dziedziny rozwoju oprogramowania. W Polsce nie wiedzie\u0107 czemu jest stosunkowo nieznany, a szkoda. Brooks zrobi\u0142 w \u017cyciu dwie wielkie rzeczy […]<\/p>\n","protected":false},"author":1,"featured_media":998,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[103,204],"tags":[155,153,117,104,118,156,154],"_links":{"self":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/989"}],"collection":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/comments?post=989"}],"version-history":[{"count":10,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/989\/revisions"}],"predecessor-version":[{"id":1024,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/989\/revisions\/1024"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/media\/998"}],"wp:attachment":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/media?parent=989"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/categories?post=989"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/tags?post=989"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}