Магчымасць хуткага мадэлявання патрабаванняў

Многія традыцыйныя праектныя каманды сутыкнуліся з праблемамі, калі яны спрабуюць вызначыць усе патрабаванні фронт, часта з'яўляюцца вынікам памылковай думкі, што распрацоўшчыкі будуць на самой справе чытаць і сачыць, што дакумент змяшчае патрабаванні. Рэальнасць такая, што патрабаванні дакумента, як правіла, недастаткова, незалежна ад таго, колькі намаганняў ідзе ў яе, змены патрабаванняў ў любым выпадку, і распрацоўнікі ў канчатковым выніку ў канчатковым выніку адбываецца непасрэдна зацікаўленых бакоў для інфармацыі ў любым выпадку (або яны проста здагадацца, што зацікаўленыя бакі на ўвазе). Agilists ведаю, што калі ў іх ёсць здольнасць выклікаць падрабязныя патрабаванні фронт, то яны таксама могуць зрабіць тое ж самае, калі яны сапраўды маюць патрэбу ў інфармацыі. Яны таксама ведаюць, што любыя інвестыцыі ў падрабязнай дакументацыі на ранніх этапах праекта будзе выдаткавана марна, калі патрабаванні непазбежна зменіцца. Agilists выбраць, каб не марнаваць час на ранніх стадыях праекта Даць падрабязную дакументаў патрабаванням, паколькі яны ведаюць, што гэта вельмі дрэнны дарозе на працу.

Змест

1. спрытны патрабаванні мадэляванне ў мініяцюры
2. Дзе патрабаванні прыйшоў?
3. Лепшыя практыкі
4. Тыпы патрабаванняў
5. Патэнцыйныя артэфакты патрабаванні
6. Метады выяўлення патрабаванняў
7. Агульныя патрабаванні праблемы мадэлявання
8. спрытны патрабаванням кіравання змяненнямі

1. спрытны патрэбаў мадэлявання ў двух словах

Малюнак 1 адлюстроўвае спрытны Model Driven Development (AMDD) жыццёвага цыкла , на якой намаляваны як спрытны мадэляванне (АМ) ужываецца спрытны распрацоўкі праграмнага забеспячэння каманды. Крытычныя аспекты, якія мы занепакоеныя цяпер з'яўляюцца пачатковымі патрабаваннямі да мадэлявання , ітэрацыі мадэлявання і мадэлі штурм . Асноўная ідэя ў тым, што ў вас у абрэз мадэлявання ў пачатку праекта, каб зразумець патрабаванні да сістэмы на высокім узроўні, то вы збіраеце дэталі, як вам трэба, каб на толькі-In-Time (JIT) аснове.

Малюнак 1 . Жыццёвы цыкл AMDD.

1,1 Першапачатковы патрэбаў мадэлявання

У пачатку праекта неабходна заняць некалькі дзён, каб прадставіць сабе высокія патрабаванні і зразумець маштабы выпуску (тое, што вы думаеце, павінна рабіць сістэма). Вашай мэтай з'яўляецца атрымаць кішкі адчуць, што праект усё о, не да дакумента падрабязна, што вы думаеце, павінна рабіць сістэма: дакументацыя можа прыйсці пазней, калі вы сапраўды ў ёй мае патрэбу. Для зыходнай мадэлі патрабаванні мой досвед паказвае, што трэба той ці іншай форме:

1. Выкарыстаньне мадэлі. Як вынікае з назвы мадэлі выкарыстання дазваляюць даследаваць, якім чынам карыстальнікі будуць працаваць з вашай сістэмай. Гэта можа быць калекцыя істотна выпадкаў выкарыстання на Rational Unified Process (RUP) праекту калекцыю асаблівасці для функцый Driven Development (FDD) праекту, ці калекцыю карыстацкіх гісторый для экстрэмальнага праграмавання (XP) праекту.
2. Першапачатковая мадэль прадметнай вобласці. Мадэлі прадметнай вобласці вызначае фундаментальныя гаспадарчага суб'екта тыпаў і адносін паміж тагачасным. Дамен мадэлі могуць быць намаляваныя ў выглядзе набору класаў Адказнасць Супрацоўніка (КПР) карт , Slim класа UML дыяграмы , ці нават тонкая мадэль дадзеных . Гэты дамен мадэль будзе ўтрымліваць дастаткова інфармацыі: асноўныя суб'екты вобласці, іх асноўныя атрыбуты і адносіны паміж гэтымі асобамі. Ваша мадэль антиплазмин павінны быць поўнымі, ён проста павінен ахопліваць дастаткова інфармацыі, каб вы камфортна з першасных паняццяў вобласці.
3. Карыстацкі інтэрфейс мадэлі. Для карыстальніцкага інтэрфейсу інтэнсіўных праектаў, якія вы павінны разгледзець пытанне аб распрацоўцы некаторых экране эскізы ці нават прататып інтэрфейсу карыстальніка .

Які ўзровень дэталізацыі вы на самой справе трэба? Мой вопыт паказвае, што вам трэба патрабаванняў артэфакты, якія ледзь дастаткова для таго каб даць вам гэта разуменне і не больш таго. Напрыклад, Малюнак 2 адлюстроўвае простая кропка-формы варыянту выкарыстання . Гэты варыянт выкарыстання можа вельмі добра былі напісаныя на картках, частка фліп-папяровай карце, або на дошцы. Ён змяшчае дастаткова інфармацыі, каб вы зразумелі, што варыянт выкарыстання робіць, і на самай справе ён можа ўтрымліваць занадта шмат інфармацыі для гэтай кропкі ў жыццёвым цыкле, таму што толькі назва варыянту выкарыстання можа быць дастаткова для зацікаўленых бакоў, каб зразумець асновы што вы маеце на ўвазе. Малюнак 3 , з другога боку, адлюстроўвае цалкам дакументаваны фармальных варыянтаў выкарыстання. Гэта выдатны прыклад таго, добра дакументаваны выкарыстання, але яна ідзе ў значна больш падрабязна, чым вы, магчыма, неабходна прама зараз. Калі вам сапраўды трэба такім узроўні дэталізацыі, і на практыцы рэдка можна зрабіць, вы можаце захапіць яго, калі вы на самой справе трэба ад мадэлі штурму яго на час. Чым даўжэй праекта ваша каманда ідзе без зваротнай сувязі канкрэтных рабочых праграмнага забеспячэння, тым больш верагоднасьць таго, што вы мадэлявання рэчы, якія не адлюстроўваюць тое, што вашыя зацікаўленыя бакі сапраўды неабходна.

Малюнак 2 . -Форма выкарыстання выпадку кропка.

Малюнак 3 . Падрабязныя выпадку выкарыстання.

1,2 ітэрацыі мадэлявання

Ітэрацыі мадэлявання з'яўляецца часткай агульнай ітэрацыі планавання намаганняў выконваецца ў пачатку ітэрацыі. Вы часта павінны вывучыць патрабаванні да крыху больш дэталёвым узроўні, чым вы рабілі першапачаткова, мадэляванне дастаткова, каб план работы, неабходныя для выканання дадзенага патрабаванні.

1,3 Мадэль Штурм

Падрабязныя патрабаванні выклікалі, ці, магчыма, лепшы спосаб думаць аб гэтым з'яўляецца тое, што высокія патрабаванні прааналізаваны, на раз своечасова аснове. Калі распрацоўнік новага патрабаванні па ажыццяўленню, магчыма, "Запісацца на семінар" выкарыстоўваць выпадку малюнку 2 , яны пытаюцца ў сябе, ці разумеюць яны тое, што прасілі. У гэтым выпадку, гэта не так ясна, сапраўды, што зацікаўленыя бакі хочуць, напрыклад, у нас няма якіх-небудзь ўказанняў на тое, што экраны павінны выглядаць. Яны таксама спытаць сябе, калі патрабаванне досыць малы, каб рэалізаваць у менш, чым дзень ці два, і калі няма, то пераўтварыць яго ў калекцыю меншыя часткі, якія яны рашэння па адным. Меншыя рэчы прасцей у рэалізацыі, чым больш буйныя рэчы.

Каб даведацца падрабязнасці гэтага патрабавання, распрацоўнікам (або распрацоўшчыкамі на праектныя групы, якія прымаюць падыходу да праграмаванні пара), просяць сваіх зацікаўленых бакоў (S), каб растлумачыць, што яны азначаюць. Часта гэта робіцца шляхам эскізы на паперы або дошцы з зацікаўленымі бакамі. Гэтыя мадэлі штурму сесій , як правіла, экспромтам падзей і звычайна доўжацца ад пяці да дзесяці хвілін (гэта з рэдкай для мадэлявання шторм больш за трыццаць хвілін, таму што патрабаванні кавалкі настолькі малыя). Людзі збіраюцца разам, збіраюцца вакол агульных інструмент мадэлявання (напрыклад, класная дошка), вывучыць пытанне, пакуль іх задаволены тым, што яны разумеюць яго, а затым яны прадоўжаць (часта кадавання). Extreme праграмістаў (XPers) назваў бы патрабаванням мадэляванне штурму сесій "кліентаў Q & сесій". У прыклад вызначэння таго, што экран будзе выглядаць, разам з зацікаўленымі бакамі (ы) вы эскіза, што жадаеце экране выглядаць, малюнак некалькі прыкладаў пакуль не прыйшлі да агульнага разумення таго, што павінна быць пабудавана. Эскізы такія як гэтага з'яўляюцца уключаючы мадэлі , таму што вы карыстаецеся простыя інструменты і метады мадэлявання, што дазволіла спрытны мадэляванне (АМ) практыкі спрытны Удзел зацікаўленых бакоў . Лепшыя людзі для мадэлявання патрабаванняў зацікаўленых бакоў, таму што яны тыя, хто экспертам у гэтай галіне, а не вы.

Падрабязны прыклад таго, як ісці аб мадэляванні патрабаванні, чытаць артыкулы спрытны Патрабаванні мадэльным прыкладзе.

2. Дзе Патрабаванні Прыходзьце з ?

Ваш зацікаўленых бакоў праекта прамых або ўскосных карыстальнікаў, менеджэраў, топ-менеджэры, супрацоўнікі аперацый, падтрымкі (Help Desk) супрацоўнікаў, тэсціроўшчыкаў, распрацоўшчыкі, якія працуюць на іншыя сістэмы, якія аб'ядноўваюць або ўзаемадзейнічаць з вашым, і абслугоўванне спецыялісты толькі афіцыйны крыніца патрабаванняў ( Так, распрацоўшчыкі могуць прапанаваць патрабаванням, але зацікаўленыя бакі павінны прыняць прапановы).   На самай справе гэта адказнасць удзельнікаў праекта, каб забяспечыць, удакладніць, вызначыць і прыярытэты патрабаванняў .   Акрамя таго, правы ўдзельнікаў праекту, што распрацоўнікам інвеставаць час, каб вызначыць і зразумець гэтыя патрабаванні.   Гэта паняцце мае вырашальнае значэнне для вашага поспеху як спрытны Modeler гэта ролі ўдзельнікаў праекта, каб забяспечыць патрабаванні, гэта ролі распрацоўшчыкаў, каб зразумець і рэалізаваць іх.

Ці азначае гэта, што вы сядзіце ў ступар чакаем вашых зацікаўленых бакоў праекта распавесці вам, што яны хочуць?   Не, вядома, няма.   Вы можаце задаваць пытанні, каб даследаваць тое, што яны ўжо сказаў вам, магчыма, аналіз дзейнасці , што дапамагае ім вызначыць больш падрабязна, што яны хочуць, і, магчыма, нават перагледзець і змяніць сваё першапачатковае патрабаванне (ы).   Вы можаце прапанаваць новыя патрабаванні да іх, ключавыя словы, якое прапаноўваюць, што яны павінны разгледзець і прыняць альбо (магчыма, з зменамі і дапаўненнямі) або адхіліць як афіцыйныя патрабаванні.   Для выяўлення патэнцыйных патрабаванняў вы можаце таксама, часта з дапамогай вашага праекта зацікаўленыя бакі, працаваць у рамках існуючых дакументаў, такіх, як карпаратыўнае кіраўніцтва палітыкай, існуючымі традыцыйнымі сістэмамі, ці публічна даступных рэсурсаў, такіх як інфармацыя аб Сеткі, кнігі, артыкулы з часопісаў, або прадуктаў і паслугамі вашых канкурэнтаў.   Яшчэ раз, гэта ваш удзельнікаў праекту, якія з'яўляюцца асноўнай крыніцай патрабаванняў, гэта іх рашэнне, а не ваша.   Я не магу быць больш рашучым аб гэтым.

Дзе вашыя зацікаўленыя бакі праекта атрымаць ідэі? Яны часта маюць любімых мазалёў аб існуючай асяроддзі, "Мне вельмі шкада, што мы маглі б зрабіць гэта.", Убачаць тое, што іх канкурэнты могуць рабіць, што яны не могуць, можа спатрэбіцца, каб пазбегнуць праблем, якія яны зведалі ў мінулым з іншых сістэм, ці, магчыма, проста бачанне новай функцыі. Некаторыя зацікаўленыя бакі, у прыватнасці, аператыўнага персаналу і старэйшых ІТ-кіравання, магчыма, патрабаванні, заснаваныя на неабходнасці інтэграцыі з існуючымі ці хутка, каб быць існуючымі сістэмамі або патрабаванні матываваныя стратэгіі ІТ, такія як скарачэнне колькасці вылічальных платформаў у вашай арганізацыі . Справа будзе зроблена ў тым, што вашыя зацікаўленыя бакі праекта павінна быць распрацоўка патрабаванняў, заснаваных на шырокім дыяпазоне матэрыялаў, тое, што вы можаце гарантаваць, што адбываецца, задаючы пытанні.

Я часта аказваецца, што ёсць істотнае значэнне ў прыцягненні каго-то з адпаведнымі экспертнымі ведамі ў сістэме, што я будую, каб дапамагчы вызначыць патэнцыйныя патрабаванні да маёй сістэме.   Напрыклад, у выпадку сістэмы электроннай камерцыі, хутчэй за ўсё, я хачу прынесці ў кагосьці з міжнародным вопытам праектавання, экспертызы падатковае права, або лагістыкі экспертызы.   Такі падыход з'яўляецца асабліва каштоўным, калі ваша арганізацыя будуе сістэмы, якая ўключае ў сябе аспекты, якія не знаёмыя з, магчыма, ваш сістэма электроннай камерцыі ваша першая спроба на абслугоўванне міжнародных кліентаў.   Я буду часта прыносяць знешнімі экспертамі на працягу дня ці двух, і з некалькімі зацікаўленымі бакамі праекта забраць свае мазгі для адпаведных пытанняў, якія мы можа адсутнічаць з-за нашай неспрактыкаванасці.   Гэта SA выдатны спосаб пераканацца, што мы паўторна пакрыццё нашых баз, у прыватнасці, калі мы вызначаем пачатковыя магчымасці для праекта, і атрымаць ўдзельнікамі праекта мыслення за межамі іх цяперашніх умовах.   Тым не менш, прызнаюць, што існуе небяспека таго, пры такім падыходзе знешнія эксперты могуць прапанаваць ідэі, якія добра гучаць, але Арэне T сапраўды неабходныя прама цяпер.   Іншымі словамі, вам усё яшчэ трэба працаваць праз прапанову ад вонкавага эксперта гэтак жа, як і любы іншы.  

3. найлепшай практыкі

Ёсць некалькі " лепшыя практыкі ", якія павінны дапамагчы вам стаць больш спрытны з мадэляванні патрабаванні:

1. Зацікаўленыя бакі актыўна ўдзельнічаць
2. уключна мадэляў Прыняць
3. Вазьміце ў шырыню падыход
4. Мадэль буру падрабязнасці Just In Time (JIT)
5. Аддаюць перавагу выкананых спецыфікацый на статычнай дакументацыі
6. Ваша мэта заключаецца ў рэалізацыі патрабаванняў, а не дакумент іх
7. Стварыць незалежны ад платформы патрабаванні да кропкі
8. Менш, тым лепш
9. Пытанне прослеживаемость
10. Растлумачце метады
11. Прыняць зацікаўленых тэрміналогіі
12. Трымайце гэта весела
13. Атрымаць падтрымку кіравання
14. Уключыце зацікаўленых бакоў у распрацоўнікаў
15. Лячыць патрабаваннямі, такімі як прыярытэтныя стэка

4. Тыпы патрабаванняў

Я тая цвёрда верыць у падзяляе патрабаванні на дзве катэгорыі:

1. Паводніцкая.   Паводніцкіх патрабаванні апісвае, як карыстальнік будзе ўзаемадзейнічаць з сістэмай (пытанні карыстацкі інтэрфейс), як хто-то будзе выкарыстоўваць сістэмы (выкарыстанне), ці як сістэма выконвае бізнес-функцыі (бізнэс-правілы). Гэта часта называюць функцыянальным патрабаванням.
2. Нумары-паводзінская. Нумары-паводніцкіх патрабаванні апісвае тэхнічныя асаблівасці сістэмы, асаблівасці звычайна якія адносяцца да даступнасці, бяспекі, прадукцыйнасці, сумяшчальнасці, надзейнасці і надзейнасці. Non-паводніцкіх патрабаванні часта называюць "нефункциональные" патрабаванні ў сувязі з дрэннай наймення Рашэнне, прынятае IEEE (наколькі я магу судзіць нефункциональные вынікае, што яна не працуе).

Гэта важна зразумець, што адрозненне паміж паводніцкіх і не паводніцкіх патрабаванняў з'яўляецца недакладнае выкананне патрабаванняў апісаннем чаканых хуткасць доступу да дадзеных відавочна тэхнічны характар, але будзе таксама адлюстравана ў адказ час карыстацкі інтэрфейс, які ўплывае на выгоду выкарыстання і патэнцыялу выкарыстанне.   Кантроль доступу пытанні, такія як: хто мае права доступу канкрэтнай інфармацыі, відавочна паводніцкіх патрабаванні, хоць яны, як правіла, лічыцца праблема бяспекі, якая трапляе ў не-паводніцкіх катэгорый.   Прыслабце трохі і Дон Т дазволіць сабе зацыклівацца на такіх пытаннях, як гэты.   Крытычнай рэч павінна вызначыць і зразумець дадзенае патрабаванне, калі вы няправільна класіфікаваць патрабаванне, хто сапраўды клапоціцца?

5. Патэнцыйныя патрабаванні Артэфакты

Таму што існуюць некалькі розных тыпаў патрабаванняў, некаторыя або ўсе з якіх могуць быць дастасавальныя да вашага праекту, і таму кожны мадэлявання артэфакт яна з моцныя і слабыя бакі, вы хочаце мець некалькі мадэлявання патрабаванняў артэфакты ў вашай інтэлектуальнай інструментарый каб быць эфектыўнымі.   У табліцы 1 коратка агульнай артэфакты для мадэлявання патрабаванняў, артэфакты, якія апісаны больш падрабязна ў артыкуле артэфактаў для спрытны мадэлявання . Тып (ы) патрабаванні, што артэфакт, як правіла, выкарыстоўваецца для мадэлі паказана, а таксама патэнцыйных просты інструмент, які вы можна выкарыстоўваць для стварэння артэфакты (важнасць выкарыстання простых інструментаў абмяркоўвалася раней у раздзеле Некаторыя філасофіі ).

Табліца 1 .   Кандыдат артэфакты для мадэлявання патрабаванняў.

Важна памятаць, што, хоць Ёсць некалькі артэфактаў, якія можна патэнцыйна выкарыстоўваць для збору патрабаванняў, што антиплазмин азначае, што вы павінны выкарыстоўваць усе з іх у той ці іншы праект. Вы павінны зразумець, калі гэта мэтазгодна выкарыстоўваць кожны артэфакт, веды , што дазволіць вам прытрымлівацца практыцы прымяняць права Артэфакт (ы) ў вашай сітуацыі.

Асноўны працэс часта матывуе артэфакт выбар. На галоўнай старонцы я паказваюць, што М. выкарыстоўваецца ў спалучэнні з іншым праграмным забеспячэннем працэсу, такія як экстрэмальнага праграмавання (XP) або уніфікаваны працэс (UP), чыя сфера з'яўляецца поўны жыццёвы цыкл.   Вельмі часта асноўны працэс будзе аддаюць перавагу некаторыя першасныя патрабаванні артэфакт (ы), у выпадку гісторыі XP карыстальнік і для UP выпадкаў выкарыстання, пытанне, які неабходна ўлічваць пры мадэляванні патрабаванняў.   Глядзіце артыкула М., XP і AM і УП для далейшых падрабязнасцяў.

6. Метады Выяўленне Патрабаванне S

Ёсць некалькі метадаў для выяўлення патрабаванняў, прадстаўлены ў табліцы 2 . Кожны метад мае кампрамісаў, маецца на ўвазе, што вам трэба вывучыць некалькі, калі вы хочаце стаць вялікі вопыт па выяўленні патрабаванняў, і кожны з іх можа быць ужыты як у спрытны і не спрытны чынам (я мяркую, што вы трымаеце яго як спрытны наколькі гэта магчыма).

Табліца 2 . выяўленне метадаў патрабаванні.

7. Агульныя патрабаванні Мадэляванне выклікі

Каб быць спрытны на патрабаванні мадэлявання вы павінны быць у сітуацыі, дзе можна дабіцца поспеху, і для многіх каманд праекту гэтага, на жаль гэта не так.   Вельмі часта намаганні патрабаванні мадэлявання падрываецца асяроддзі яна з'яўляецца агульнай, выявіўшы, што хіба арганізацый культуры, якая спрыяе эфектыўнай распрацоўкі праграмнага забеспячэння або намаганняў удзельнікаў праекта не разумеюць наступстваў сваіх рашэнняў.   У гэтым раздзеле я выявіць агульныя праблемы, што шматлікія каманды распрацоўшчыкаў твар, калі справа даходзіць да мадэлявання патрабаванняў і абмеркаваць магчымыя рашэнні для вырашэння гэтых праблем. Гэтыя агульныя праблемы (па спасылцы, каб даведацца, як пераадолець іх):

1. Абмежаваны доступ да ўдзельнікаў праекта

2. Геаграфічна размеркаваныя удзельнікаў праекта

3. Праект зацікаўленыя бакі не ведаюць, чаго хочуць

4. Праект зацікаўленых бакоў змяніць сваё меркаванне

5. Канфліктуючыя прыярытэты

6. Занадта шмат зацікаўленых бакоў праекту хочуць удзельнічаць

7. Удзельнікаў праекта загадваюць тэхналагічных рашэнняў

8. Праект зацікаўленых бакоў не ў стане бачыць далей бягучай сітуацыі

9. Удзельнікаў праекта баяцца быць убачанымі

10. Удзельнікаў праекта не разумею мадэлявання артэфактаў

11. Распрацоўнікі не разумеюць праблемы вобласці

12. Удзельнікамі праекта з'яўляюцца празмерна засяроджана на адным выглядзе патрабаванні

13. Удзельнікаў праекта запатрабуе значных фармальнасці, якія тычацца патрабаванняў

14. Распрацоўнікі не разумеюць патрабаванняў

8. спрытны Змяненне кіравання патрабаваннямі

спрытны каманд распрацоўнікаў праграмнага забеспячэння ахоплівае змены, прымаючы ідэю, што патрабаваньні будуць развівацца па ўсім праекце. Agilists зразумець, што, паколькі патрабаванні змяняюцца з часам, што любыя інвестыцыі ў раннім падрабязная дакументацыя будзе толькі марна. Замест agilists будзе рабіць толькі досыць пачатковых мадэлявання для вызначэння іх маштабу праекта і распрацоўкі высокага ўзроўню графіка і ацэнкі; вось і ўсе вы сапраўды мае патрэбу ў пачатку праекта, дык вось і ўсе вы павінны зрабіць. У працэсе распрацоўкі яны будуць мадэлі бура ў толькі ў тэрмін чынам вывучыць кожнае патрабаванне з усімі неабходнымі падрабязнасцямі.

Так як патрабаванні часта мяняюцца, неабходна абцякальнай, гнуткі падыход да кіраванню змяненнямі патрабаванняў . Agilists хочам развіваць праграмнае забеспячэнне, якое з'яўляецца адначасова высокай якасці і высокай кошту, і самы просты спосаб распрацоўкі высокага кошту праграмнага забеспячэння для рэалізацыі прыярытэтных самым высокім патрабаванням у першую чаргу. Agilists імкнуцца па-сапраўднаму кіраваць зменамі, а не каб прадухіліць яго, даючы ім магчымасць максімальна зацікаўленых ROI . Імя праграмнае забеспячэнне каманда распрацоўнікаў стэк прыярытэтнасць патрабаванняў якая павінна быць рэалізаваная XPers будзе літаральна стэк карыстальніка гісторыі, напісаныя на картках. Каманда займае высокія патрабаванні прыярытэт вяршыні стэка якіх яны лічаць, што яны могуць рэалізаваць у рамках бягучай ітэрацыі. Scrum мяркуе, што вы замарозіць патрабаванні да бягучай ітэрацыі, каб забяспечыць узровень стабільнасці для распрацоўнікаў. Калі вы зробіце гэта, то любыя змены ў патрабаванні ты ў цяперашні час ажыццяўляе варта разглядаць толькі як адзін новае патрабаванне.

Малюнак 4 агляды спрытны падыход да кіравання працоўнымі элементамі патэнцыйна трэба быць дасягнута шляхам каманды (вы не можаце на самой справе маюць дастаткова часу або рэсурсаў для выканання ўсіх пунктаў). Гэты падыход адлюстроўвае Адкрыць Unified Process (OpenUP) 'S падыход да працы кіравання, якая з'яўляецца пашырэннем Scrum падыход да метадалогіі кіравання патрабаваннямі. Дзе Scrum разглядае патрабаванні як прыярытэтныя стэка называецца прадукт адставання, OpenUP займае яшчэ адзін крок наперад, каб прызнаць, што не толькі вы рэалізуеце патрабаванні часткай вашай паўсядзённым працы, але вы таксама не-патрабаванне, звязанае працы, такія як прайсці навучанне, пайсці на адпачынак, агляд прадуктаў іншых каманд, і гэтак далей. Новыя працоўныя элементы, у тым ліку дэфектаў, выяўленых у рамках вашай дзейнасці карыстацкага тэсціравання, з'яўляюцца прыярытэтнымі вашым зацікаўленых бакоў праекта і дададзены ў стэк ў адпаведным месцы. Ваш зацікаўленых бакоў праекта маюць права вызначаць новыя патрабаванні, зменяць сваё меркаванне аб існуючых патрабаванняў, і нават reprioritize патрабаванні, як яны лічаць патрэбным. Тым не менш, зацікаўленыя бакі павінны таксама несці адказнасць за прыняцце рашэнняў і прадастаўлення інфармацыі ў устаноўленыя тэрміны.

Малюнак 4. спрытны патрабаванняў працэс кіравання зменамі .

 

Распрацоўшчыкі нясуць адказнасць за ацэнку намаганняў, неабходных для рэалізацыі патрабаванняў, якія яны будуць працаваць. Хаця вы, магчыма, асцерагаюцца, што распрацоўшчыкі не павінны неабходнымі навыкамі ацэнкі, і гэта часта справядліва па-першае, той факт, што яна doesn't зойме шмат часу для людзей, каб атрымаць даволі добрую адзнаку, калі яны ведаюць, што Theyre збіраецца павінны жыць да тых ацэнак. Для атрымання дадатковай інфармацыі азнаёмцеся спрытны Змяненне кіравання патрабаваннямі .

9. Рэкамендаваны рэсурсы

Актыўны ўдзел зацікаўленых бакоў   спрытны Аналіз спрытны Model Driven Development (AMDD) спрытны Патрабаванні Best Practices спрытны Патрабаванні Кіраванне зменамі спрытны Software Development і бізнес-аналізу (Патрабаванні сеткі, сяброўства абавязкова) Рэкамендацыі па спрытны / Lean Дакументацыя "Змяненне папярэджанні" анты-патэрна Параўноўваючы розныя падыходы да мадэлявання ў распрацоўцы праграмнага забеспячэння Падрабязнае тэхнічнае заданне: Горшы практыцы? Фазы развіцця разглядаюцца: Чаму патрабаванні, аналіз і дызайн больш не маюць сэнсу Дакумент позна: спрытны Лепшая практыка Доказы таго, што спрытны Software Development шалі Экспертызы "Вялікі Патрабаванні Да фронту (BRUF)" Падыход Першапачатковы высокага ўзроўню архітэктурнага прадбачанне Пачатковага ўзроўню Патрабаванні да сярэдняй выпрацоўкі канцэпцыі Ітэрацыя Мадэляванне "Мадэль трохі наперад" План "Адна ісціна Перш за ўсё астатняга" анты-патэрна Прыярытэтныя патрабаванні: спрытны Лепшая практыка Пераасэнсаванне, як Вы разглядаеце Упраўленне патрабаваннямі UML-профіль для мадэлявання дадзеных Нязменнага правілы зменамі праграмнага забеспячэння

спрытны Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how спрытны software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the спрытны Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including спрытны projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an спрытны manner.

		Аб'ект Primer 3rd Edition: спрытны Model Driven Development з UML 2 з'яўляецца важным даведнікам для гнуткай мадэльераў, якія апісваюць, як распрацаваць 35 тыпаў гнуткіх мадэляў , уключаючы ўсе 13 UML 2 дыяграм . Акрамя таго, гэтая кніга апісвае метады поўнага жыццёвага цыкла аб'ектна-арыентаванага тэставання (FLOOT) метадалогіі, каб даць вам асноўныя навыкі тэсціравання, якія вы патрабуеце, каб атрымаць поспех у хуткай распрацоўкі праграмнага забеспячэння. У кнізе таксама паказана, як перамясціць з гнуткай мадэлі да зыходнага коду ( Java прыклады прыводзяцца), а таксама як дабіцца поспеху ў рэалізацыі такіх метадаў, як рэфактарынгу і тэст-Driven Development (TDD) . Аб'ект Primer таксама ўключае кіраўніка overviewing крытычных метадаў распрацоўкі баз даных ( базы дадзеных рэфактарынгу , аб'ектна-рэляцыйнага адлюстравання , аналізу спадчыны , і доступ да базы дадзеных кадавання) з майго ўзнагародамі спрытны Database метадам кнігі.
		Элементы UML 2.0 Стыль апісвае набор стандартаў, канвенцый, і кіруючыя прынцыпы для стварэння эфектыўнай дыяграм UML . Яны заснаваны на надзейных, правераных праграмнага забеспячэння прынцыпаў, якія прыводзяць да схемах, якія лягчэй зразумець і працаваць. Гэтыя канвенцыі існаваць як сукупнасць простых, кароткія кіруючыя прынцыпы, якія, калі ўжываць паслядоўна, уяўляюць сабой важны першы крок у павышэнні прадукцыйнасці, як мадэльер. Гэтая кніга арыентавана на сярэдні і прасунуты мадэльераў UML, хоць Ёсць мноства прыкладаў у кнізе не было б добрым спосабам даведацца UML (замест гэтага, разгледзець аб'ект Primer ). Кніга ўяўляе сабой кароткае 188 старонак і зручна кішэнны таму лёгка насіць з сабой.

10. Пераклады

Кітайскі пераклад Гао Lucky

11. Дазвольце мне дапамагчы

Я актыўна працаваць з кліентамі па ўсім свеце, каб палепшыць свае інфармацыйныя тэхналогіі (ІТ) практыкі, як настаўнік / трэнерам і трэнерам. Падрабязнае апісанне таго, што я раблю, і як са мной звязацца, можна знайсці тут .

Вы можаце быць зацікаўлены ў маёй двухдзённай спрытны Патрабаванні Семінар: нешта старое, тое новае, што-то ўзяў, нічога Blue