реферат | Тестування. | глосарій |

загрузка...
загрузка...
На головну

Замовник завжди поруч.

Основною проблемою розробки програмного забезпечення є брак знань програмістів в розроблюваної предметної області. Екстремальне програмування знайшло вихід і з цієї ситуації. Ні, це не стажування розробника на підприємстві замовника - він тоді не захоче програмувати. Навпаки, це участь замовника в процесі розробки.
 Хіба може програміст, досконально не розуміючи суть питання і не будучи телепатом, вгадати, чого хоче замовник? Відповідь очевидна. Найпростішим способом подолати таку незручність - а екстремальне програмування вчить нас знаходити найпростіші рішення - буде задати замовнику пряме запитання. Строгіші підходи вимагають всеосяжного попереднього аналізу розробляється області. У певних випадках це виправдано, хоча і дорожче обходиться. Реальний досвід ведення приземлених проектів показує, що неможливо зібрати всі вимоги заздалегідь. Більш того, навіть якщо припустити, що всі вимоги на поточний момент зібрані, все одно залишиться одне вузьке місце: програми, як і все в природі, не створюються миттєво, а тим часом бізнес-процеси можуть помінятися. Це слідвраховувати.

Багато хто сумнівається в можливості залучення замовника до процесу розробки. Дійсно, замовники бувають різні. Якщо залучити замовника або його представника не вдається, іноді виявляється доцільним тимчасовий найм фахівця в розроблюваної області. Такий крок скоротить неясності в роботі, підвищить швидкість розробки і наблизить проект до того, що бажає отримати замовник. Це може бути вигідно і з фінансової сторони: адже оплата праці програміста часом значно перевищує оклад фахівців інших галузей.

Живе планування.

Його завдання - якомога швидше визначити обсяг робіт, які потрібно зробити до наступної версії ПЗ. Рішення приймається, в першу чергу, на основі пріоритетів замовника (тобто його потреб, того, що потрібно йому від системи для більш успішного ведення свого бізнесу) і, в другу, на основі технічних оцінок (тобто оцінок трудомісткості розробки , сумісності з іншими елементами системи та ін.). Плани змінюються, як тільки вони починають розходитися з дійсністю або побажань замовника.

рис.1 Схема потоку робіт в XP

 



Парне програмування. | Використання коду як засоби комунікації
загрузка...
© um.co.ua - учбові матеріали та реферати