{"id":532,"date":"2022-01-26T01:29:30","date_gmt":"2022-01-26T01:29:30","guid":{"rendered":"https:\/\/www.cybermedian.com\/pl\/?p=532"},"modified":"2025-02-17T11:43:51","modified_gmt":"2025-02-17T03:43:51","slug":"how-to-manage-product-backlog-with-deep-principles","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/pl\/how-to-manage-product-backlog-with-deep-principles\/","title":{"rendered":"Jak zarz\u0105dza\u0107 backlogiem produktu zgodnie z zasadami DEEP?"},"content":{"rendered":"
\n
\n
\n

\u00a0backlog produktu<\/a>\u00a0jest uporz\u0105dkowan\u0105 list\u0105 wszystkiego, co jest znane i potrzebne w produkcie. Jest to jedno \u017ar\u00f3d\u0142o zapotrzebowania na wszelkie zmiany w produkcie.<\/p>\n

\n

W\u0142a\u015bciciel produktu jest odpowiedzialny za backlog produktu, w tym jego zawarto\u015b\u0107, dost\u0119pno\u015b\u0107 i kolejno\u015b\u0107.<\/p>\n<\/blockquote>\n

Lista backlogu produktu nigdy nie b\u0119dzie uko\u0144czona. Zmiany w potrzebach biznesowych, warunkach rynkowych lub technologii mog\u0105 prowadzi\u0107 do zmian w li\u015bcie zada\u0144 do wykonania produktu. Ewoluuje wraz z rozwojem produkt\u00f3w i zmianami w otoczeniu projektu. Wymagania projektu nigdy nie przestaj\u0105 si\u0119 zmienia\u0107, wi\u0119c lista zada\u0144 do wykonania produktu jest jak stale ewoluuj\u0105cy artefakt scrumowy.<\/p>\n

Elementy o wysokim priorytecie w backlogu produktu s\u0105 szczeg\u00f3\u0142owe. Poniewa\u017c te projekty maj\u0105 wi\u0119cej informacji i szczeg\u00f3\u0142\u00f3w, a tym samym maj\u0105 dok\u0142adniejsze oszacowania.<\/p>\n

Projekty o ni\u017cszym priorytecie s\u0105 wi\u0119ksze i maj\u0105 mniej jasne szczeg\u00f3\u0142y. W miar\u0119 jak zesp\u00f3\u0142 uzyskuje bardziej szczeg\u00f3\u0142owe informacje o projektach o niskim priorytecie, b\u0119d\u0105 one dalej dzielone na mniejsze. Zesp\u00f3\u0142 deweloperski jest odpowiedzialny za ocen\u0119 tych element\u00f3w w backlogu produktu od czasu do czasu.<\/p>\n

DEEP w zarz\u0105dzaniu backlogiem produktu<\/h3>\n

Backlog produktu zawiera wszystkie funkcje, funkcjonalno\u015bci, wymagania, ulepszenia i poprawki wymagane do wydania produktu. Projekty backlogu produktu maj\u0105 atrybuty opisu (odpowiednio\u00a0D<\/strong>etalizowany), punkty historii (E<\/strong>stymacje), oraz zam\u00f3wienia (P<\/strong>riorytetyzowane). Musz\u0105 by\u0107 ci\u0105gle dodawane, usuwane i aktualizowane (E<\/strong>mergent) w backlogu i odzwierciedla\u0107 zrozumienie backlogu zespo\u0142u w odpowiednim i terminowym spos\u00f3b.<\/p>\n

Roman Pichler jest autorem Agile Product Management with Scrum, wspomnianym:<\/p>\n

\n

\u201eTworzenie produkt\u00f3w, kt\u00f3re klienci kochaj\u0105. U\u017cywamy czteroliterowego skr\u00f3tu DEEP, aby opisa\u0107 cechy dobrego backlogu produktu.\u201d jest to opisowy skr\u00f3t dla jako\u015bci backlogu produktu w Scrum, kt\u00f3ry oznacza:D<\/strong>etalizowany odpowiednio,E<\/strong>mergent,E<\/strong>stymowany iP<\/strong>riorytetyzowany.<\/p>\n<\/blockquote>\n

<\/figure>\n

Szczeg\u00f3\u0142owo odpowiednio<\/h3>\n

Historie blisko szczytu backlogu produktu b\u0119d\u0105 realizowane w nast\u0119pnymsprint<\/a>, wi\u0119c te elementy musz\u0105 by\u0107 wystarczaj\u0105co dobrze zdefiniowane, aby zesp\u00f3\u0142 m\u00f3g\u0142 nad nimi pracowa\u0107 bardziej produktywnie. Zazwyczaj historie blisko szczytu backlogu s\u0105 mniejsze i bardziej szczeg\u00f3\u0142owe, ale staj\u0105 si\u0119 coraz wi\u0119ksze i mniej specyficzne w dalszej cz\u0119\u015bci listy backlogu produktu, jak pokazano na poni\u017cszym rysunku:<\/p>\n

<\/figure>\n

Oszacowane<\/h3>\n

Elementy w backlogu produktu s\u0105 oszacowane. Elementy na szczycie backlogu maj\u0105 dok\u0142adniejsze oszacowania. Elementy o ni\u017cszym priorytecie s\u0105 oszacowane na wysokim poziomie i mog\u0105 by\u0107 ponownie oszacowane, gdy zesp\u00f3\u0142 uzyska wi\u0119cej informacji.<\/p>\n

<\/figure>\n

Ewolucyjny<\/h3>\n

Backlog produktu nie jest statyczny, jest w ci\u0105g\u0142ej zmianie. W miar\u0119 post\u0119pu projektu uzyskuje si\u0119 coraz wi\u0119cej informacji i wiedzy, a historie u\u017cytkownik\u00f3w w backlogu produktu s\u0105 r\u00f3wnie\u017c dodawane, usuwane lub reorganizowane.<\/p>\n

<\/figure>\n

Priorytetyzowany<\/h3>\n

W backlogu produktu, im bardziej warto\u015bciowy, tym wy\u017cszy priorytet wpisu, powy\u017cej, tym ni\u017csza warto\u015b\u0107 wpis\u00f3w w backlogu produktu, tym ni\u017cszy priorytet, nast\u0119puj\u0105cy w backlogu produktu. Zespo\u0142y zawsze ko\u0144cz\u0105 wpisy o wysokim priorytecie, aby zapewni\u0107 maksymalizacj\u0119 warto\u015bci rozwijanego produktu lub systemu.<\/p>\n

<\/figure>\n

Podsumowanie<\/h3>\n

DEEP to u\u017cyteczna koncepcja do zastosowania wudoskonalaniu backlogu produktu<\/a>procesie, kt\u00f3ry obejmuje dodawanie szczeg\u00f3\u0142\u00f3w, oszacowa\u0144 i kolejno\u015bci do element\u00f3w w backlogu produktu i utrzymywanie go w dobrej formie.<\/p>\n

Podczas udoskonalania backlogu produktu, elementy s\u0105 przegl\u0105dane i poprawiane. Zesp\u00f3\u0142 Scrum decyduje, jak i kiedy dokonuje si\u0119 udoskonalenia. Udoskonalenie zazwyczaj nie zajmuje wi\u0119cej ni\u017c 10% pojemno\u015bci zespo\u0142u deweloperskiego. Jednak elementy backlogu produktu mog\u0105 by\u0107 aktualizowane w dowolnym momencie przez w\u0142a\u015bciciela produktu lub wed\u0142ug jego uznania.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Referencje<\/h4>\n