Предполагам, че всички вече знаят това, но като начало трябва да се помни, че Product Backlog в Scrum е списък с приоритетни елементи. Подреден списък с всичко, което трябва да бъде добавено към продукта. И използвам думата артикул като нещо общо и съзнателно двусмислено, защото въпреки че типичното е да се използват „потребителски истории“, това не пречи, че в изоставането на Продукта може да има и други „неща“.
За повече информация относно казаното дотук бих прочел Продуктовото изоставане, Продуктовия гантлог и други същества и същества и Приоритизиране на продуктовото изоставане.
И сега вървим с това, което исках да напиша днес ...
Размер на натрупаните продукти? Колко артикула?
Очевидно няма правило, няма правило относно броя на артикулите, които даден продукт трябва да има, би било абсурдно, ако има такива, зависи от много фактори. Това, което можем да направим, е да съберем набор от добри практики, които ще ви насочат към него и ще видите, че всички те ще продължат по линия на намаляване на „теглото си“, размера си.
Като първа идея, тъй като се намираме в „итеративен и инкрементален“ жизнен цикъл, ориентиран към промяна, не е необходимо всички елементи да започват да работят. Обикновено можете да започнете с първо подмножество (някои справки за това тук), повече от достатъчно за първи или няколко спринта.
Натрупването на продукти нараства и се променя, тъй като се научават повече за продукта и неговите клиенти, следователно ...
Натрупването на продукти никога не е пълно
В по-традиционните модели на работа той не е започнал, докато така наречената спецификация на изискванията не бъде напълно затворена, което освен това беше предвидено, че след като се затвори, няма да се движи. За разлика от това, по дефиниция, Product Backlog никога не е завършен.
Прекарването на време в пускането на артикули в Product Backlog, по които предвидимо ще се работи в рамките на много спринтове, води до загуба, която с течение на времето те нямат смисъл, променят се, се елиминират.
Ефектът на съхранение
В допълнение, прекарването на време в попълването на Продуктовия резерв с елементи може да доведе до типичния „ефект на складово помещение“, този, в който човек пази нещата, да не ги изхвърля, времето минава, дори да забравя за тях и дори да купува тези неща отново защото не си спомнях, че съм ги спасил.
Ако нещо е било в Product Backlog твърде дълго ... изтрийте го, ако е било наистина важно ... ще се появи отново.
Натрупване на продукти като инвентар
И ако само (повтарям, само) го виждате от постната гледна точка (и тук не отивам по-нататък, защото влизането в Agile срещу Lean, в този момент, ще има своята дълбочина), елементите в Product Backlog act като "инвентар", неща, които там консумират и не генерират печалба и това е ... отпадъци
Много елементи за приоритизиране по-дълго отнема приоритизиране
Натрупването на продукти се приоритизира по стойност. Поне една подгрупа, тази с най-висок приоритет, е с приоритет. Опитайте се наборът да бъде с приоритет минимален.
Представете си 100 елемента в Product Backlog, възможните комбинации, когато се приоритизират един след друг, са повече от броя на атомите във Вселената .
Настроики ...
Ако трябва да имате дългосрочна видимост, спестете вероятни неща, но не искате да губите време в подробности, не забравяйте, че имате и други опции, като например използване на „Теми“ или „Епични“, които, когато времето дойде, ще бъде подробно описано в елементи от по-ниско ниво.
Доцент доктор. по компютърни науки, докторантура в Карнеги Мелън (САЩ) и компютърен инженер.
Първият път ми се наложи да правя Agile мениджмънт в компания. година 2001. Оттогава съм работил в или повече от 90 години. И съм обучил повече от 2000 ученици.
Аз също съм преподавател в университета Рей Рей Хуан Карлос.