[БЕЗПЛАТЕН Уебинар] Embracing Agility: Roadmap to Scaling Your Agile Transformation

Подсигурете успеха на своята Agile трансформация с насоки за нейното скалиране на организационно ниво и сформиране на персонален бленд от модерни подходи и системи. Научете повече ТУК.

PMI-PBA® домейн 4: Проследяване и Контрол (Traceability and Monitoring)

Има нещо неизбежно в проектите (и живота като цяло) – промяната. Без значение колко много планиране, събиране, преразглеждане и одобрение на изискванията извършва бизнес анализаторът – винаги трябва да очаква и да бъде подготвен за промяна. В следващата статия от PMI-PBA® серията ще се фокусираме върху това как да поставяме граници, да оценяваме въздействие и да контролираме промени към изискванията, така че ще разгледаме различните дейности, които съставляват четвъртия PMI-PBA® домейн: Проследяване и Контрол (Traceability and Monitoring).

Какво се счита за промяна? Как да знаем какви са границите на нашите проектни изисквания? Отговорът на този въпрос е една дума – обхват (baseline). Всички одобрени задачи са в очертанията на обхвата на проекта. Всичко останало, което не е включено в него, подлежи на одобрение. Веднъж щом изискванията са одобрени, те могат да бъдат променяни само чрез процедурите за контрол на промените, дефинирани за дадения проект. Форматът и степента на формалност приложени към промените варират в зависимост от методологията (product life cycle), сложността на проекта, броят на заинтересованите страни и рискове, и организационните процеси за управление на промяната. Проект, който използва waterfall методологията е по-вероятно да прилага по-формален и сложен процес за контролиране на промените, а agile практиките обикновено използват не толкова формален процес.

За да обясня домейна за Проследяване по по-конкретен начин, ще се постарая да отговоря на следните въпроси:

Какво е проследяване?

Просто казано, проследяването е мониторинг на изискванията от тяхното начало до очакваните крайни резултати, които ще изпълнят.

Какво трябва да следим?

Трябва да внимаваме с качеството и количеството на информацията, която проследяваме или иначе ще попаднем в безкраен и безполезен омагьосан кръг (loop). Това, което трябва да проследяваме е специфично за всеки отделен проект, но диаграмата по-долу представя обобщен списък:

Как да извършваме проследяване?

Подходящите инструменти за извършване на проследяване и контролиране зависят от организационните практики и наличния софтуер. Лесен метод, който включва любимия на всички Excel, е requirements traceability matrix. Често срещани атрибути на матрицата включват:

  • ID на изискванията (също Requirement Parent ID) и Описание
  • Версия
  • Приоритет
  • Собственик
  • Статус
  • Use Case ID – ID на use case, които изпълнява даденото изискване
  • Рефериращи документи
  • Клас/ Метод/ Функция/ Процедура – в които е имплементирано изискването
  • Test Case Номер – къде и как ще бъде тествано изискването
  • Tester/Developer – кой е имплементирал/ тествал изискването

Тъй като е йерархична, матрицата лесно поддържа анализ на зависимости и на въздействия. Когато нови изисквания се появят или настоящи такива се променят, те се документират, добавят се към traceability matrix, оценява се тяхното въздействие върху проекта и продукта и се представят на заинтересованите страни за одобрение.

Какво е заявка за промяна, процедура за контрол, съвет за контрол на промените?

Заявка за промяна е формалното предложение за промяна. Тъй като трябва да контролираме промените, които се правят върху обхвата на проекта, ние имаме нужда от установен процес за тази цел – процедура за контрол на промените. И тъй като е необходим и упълномощен орган да разгледа, оцени, одобри, отложи или да отхвърли промените в проекта, се нуждаем от съвет за контрол на промените (change control board) (който често се назовава като CCB).

Как бизнес анализът се свързва с управлението на промени?

Управлението на промени е в интерес и на ръководителя на проекта и на бизнес анализатора. Проектният ръководител е ангажиран с всички въпроси отнасящи се до обхвата на проекта, докато бизнес анализаторът е ангажиран с обхвата на продукта – поддържайки целостта на изискванията и асоциираните очаквани крайни резултати, както и подсигуряването на това, че всяко ново изискване е в съгласие с бизнес нуждите и целите на бизнеса и проекта. При всички случаи, и двете роли трябва да работят заедно и да комуникират относно предложените промени.

В следващата статия от PMI-PBA® серията ще разгледаме детайлите от последния домейн Оценяването – как да валидираме решение или част от него, колко често да оценяваме и какви инструменти и техники да използваме, за да подсигурим, че решението отговаря на бизнес нуждите зададени от заинтересованите лица.

Вижте повече тук за: 


PMI-PBA е регистрирана марка на Project Management Institute, Inc.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close