{"id":1388,"date":"2020-04-28T08:22:00","date_gmt":"2020-04-28T06:22:00","guid":{"rendered":"https:\/\/agileinstitute.pl\/?p=1388"},"modified":"2020-04-29T09:38:24","modified_gmt":"2020-04-29T07:38:24","slug":"nie-wszystko-od-razu-nadawanie-priorytetow","status":"publish","type":"post","link":"https:\/\/agileinstitute.pl\/index.php\/2020\/04\/28\/nie-wszystko-od-razu-nadawanie-priorytetow\/","title":{"rendered":"Nie wszystko od razu! Nadawanie priorytet\u00f3w!"},"content":{"rendered":"\n

Nie wszystko od razu! Nadawanie priorytetów!<\/strong><\/h2>\n\n\n\n

Nadawanie priorytetu zadań to bardzo ciekawy i ważny aspekt w procesie szacowania oprogramowania. Nie ma jednoznacznej odpowiedzi na to, jak to robić. Problem pojawia się w momencie, gdy biznes dużo oczekuje, terminy są krótkie, a zasoby ograniczone – znasz to?<\/p>\n\n\n\n

Dla strony biznesu, dość często wszystkie wymagania są najważniejsze. Niestety, nie ma możliwości wytworzenia wszystkiego od razu. Należy dokładnie przemyśleć, które wymagania są priorytetowe i najważniejsze z perspektywy użytkownika. W przypadku priorytetyzacji, moim zdaniem warto zawsze pamiętać o grupie docelowej tworzonego oprogramowania oraz jej satysfakcji z poszczególnych funkcjonalności. Nie wszystko co nam się wydaje „super”, takie samo będzie dla użytkownika.<\/p>\n\n\n\n

Najbardziej popularne techniki priorytetyzacji:<\/strong><\/h2>\n\n\n\n

Technik priorytetyzacji wymagań istnieje co najmniej kilka. Oczywiście, każda z nich ma swoje plusy oraz minusy. To jaka metoda zostanie wybrana, nie ma większego znaczenia, jeśli odzwierciedlają wymagania biznesu.<\/p>\n\n\n\n

1.Metoda MoSCoW:<\/strong><\/h3>\n\n\n\n

Jest to najczęściej stosowana metoda do priorytetyzacji<\/strong> Backlogu Produktu. Jejpomysłodawcą jest Dai Clegga. Polega ona na tym, że każdy element naszego Backlogu, jest przydzielany do jednej z kategorii:<\/p>\n\n\n\n

M – Must Have: <\/em><\/strong>wymagania, których implementacja jest najważniejsza oraz konieczna w przypadku budowy produktu MVP<\/a>,<\/p>\n\n\n\n

S – Should Have:<\/em><\/strong> wymagania, które są ważne, ale jest możliwe ich obejście,<\/p>\n\n\n\n

C – Could Have: <\/em><\/strong>wymagania, które nie dostarczają nowych funkcjonalności,<\/p>\n\n\n\n

W – Want \/ Won’t<\/em><\/strong> have: wymagania, których nie zrealizujemy w najbliższym czasie.<\/p>\n\n\n\n

 Metoda MoSCoW wyróżnia się prostotą oraz zrozumieniem przez każdego z członków zespołu.<\/p>\n\n\n\n

2. Model Systemico:<\/strong><\/h3>\n\n\n\n

Jest to metoda w której powstaje mapa historyjek użytkownika. Dzięki odpowiedniemu umiejscowieniu historyjek na roadmapie, otrzymujemy ich priorytety oraz wgląd na funkcjonalności produktu. Mapa definiuje główne cele użytkownika oraz zaangażowanie.<\/p>\n\n\n\n

3. Model Kano:<\/strong><\/h3>\n\n\n\n

To metoda, która została stworzona pod koniec XX wieku przez Noriaki Kano. Metoda jest skupiona na zadowoleniu klient<\/a>a poprzez badanie jego satysfakcji. Główne założenia tej metody to:<\/p>\n\n\n\n