методики, більший розмір команди руйнує необхідну для успіху простоту комунікації і робить неможливим застосування багатьох перерахованих прийомів.
Достоїнствами XP, якщо його вдається застосувати, є велика гнучкість, можливість швидко і акуратно вносити зміни в ПО у відповідь на зміни вимог і окремі побажання замовників, висока якість виходить в результаті коду і відсутність необхідності переконувати замовників у тому, що результат відповідає їх очікуванням.
екстремальне програмування моделювання бізнес
Опис моделі В«Організація процесу екстремального програмуванняВ»
Організацію процесу екстремального програмування можна представити у вигляді послідовно виконуваних операцій.
На першому етапі команда розробників, що працюють у стилі XP, очікує надходження замовлення. Як тільки надходить замовлення, менеджер команди вирішує - брати це замовлення чи ні. Критеріями відбору є такі фактори як зайнятість команди, складність проекту, досвід команди у цій галузі, ну і, в кінцевому рахунку, бажання і здатність реалізувати проект. На цьому етапі полягає попередній договір між замовником і розробниками. p align="justify"> Далі, якщо команда береться реалізовувати проект, вона просить представників замовника скласти картки з історіями. Історія (story) - деяка річ, яку за бажанням замовника повинна робити система. Потім ці картки досліджуються розробниками на предмет можливості програмної реалізації історій і їх доцільності. Якщо у програмістів з'являються зауваження щодо історій, наданих замовником, картки відправляються на повторну переробку. Як тільки розробники отримують список історій, який влаштовує їх і замовника, вони переходять до планування і погодження дати випуску версії програми і укладають договір із замовником. p align="justify"> Потім починається короткий (швидкий) процес планування. В«ВкидатиВ» метафора системи. Системна метафора (system metaphor) - історія, що описує логіку роботи системи, яку можуть розповісти будь-які учасники проекту - замовники, програмісти та менеджери. Далі всі члени команди - менеджери, інструктора, представники замовника, програмісти та ін займаються планування версії системи: відбирають історії, реалізація яких більш пріоритетна для бізнесу (для того щоб якнайшвидше запустити програмний продукт у реальне виробництво), а також придумують основні методи , засоби і технології, які будуть використані при реалізації даної версії. Планування триває поки всі учасники процесу не прийдуть до єдиного рішення, яке буде всіх влаштовувати як з точки зору витрат ресурсів, так і з точки зору часових витрат і буде найбільш оптимальним у конкретній ситуації. p align="justify"> Далі переходять безпосередньо до процесу програмування. Паралельно проходить процес модульного автоматизованого тестування написаного коду. Програмісти працюють в парах і після написання чергової функціональності, виконавши рефакторінг, протестувавши її на працездатність, інтегрують код в основний проект. Потім тестують весь проект в цілому, щоб переконатися, що все працює. Під час всього процесу розробки в офісі з програмістами перебувають представники замовника, які повинні відповідати на всі питання команди, що виникають в процесі розробки. Таким чином, здійснюється миттєва зворотній зв'язок. p align="justify"> Коли реалізація версії закінчується, вона переходить до функціонального тестування, яке здійснюють представники замовника. На цьому етапі можливо кілька ситуацій:
В· в програмі виявлені помилки - версія продукту відправляється на доопрацювання;
В· замовник бачить необхідним додавання нової історії в поточну версію програми - версія продукту відправляється на доопрацювання;
В· версія схвалена і готова для введення в експлуатацію на підприємстві;
На підприємстві програму експлуатую реальні користувачі, і розробники можуть відразу простежити поведінку системи, побачити потреби бізнесу. Також замовник може оцінити ефективність роботи розробленого програмного забезпечення і прийняти рішення про те, чи потрібно йому продовжувати співпрацювати з розробниками. Якщо проект збитковий або замовник не бачить сенсу в його подальшій модернізації, проект згортається. Інакше, в разі успіху проект приносить прибуток, В«апетитВ» замовника підвищується - він пропонує нові історії для модернізації. Після чого починається оцінка цих історій і розробка чергової версії програми. p align="justify"> Висновок
При розгляді даної схеми може виникнути відчуття, що організація процесу екстремального програмування нічим не відрізняється від класичного підходу до розробки програмного забезпечення. Насправді це не так. Нижче перераховані основ...
