Екстремальне програмування
Уявіть собі це: проект розробки програмного забезпечення для нового продукту, що базується на першій ринковій перевазі, щойно помічений на радарі вашої компанії. Традиційні методи екстремального програмування, де клієнт «точно» знає, чого хоче, відсутній. Ваша команда невелика і складається з молодих фахівців, які, ймовірно, добре реагують на радикальну модель управління проектами. Які ваші варіанти?
Ви, швидше за все, скажете, Agile Project Management, звичайно! Але яку методологію ви б хотіли використати? Існує кілька варіантів: для одного існує надзвичайно популярний Scrum: що включає створення коротких «спринтів» на основі відставання завдань від клієнта. А потім, є Kanban, який працює над оптимізацією трубопроводу. Існує також Екстремальне програмування, яке часто скорочується до XP, яке фокусується на посиленні позитивних аспектів традиційних моделей програмування, щоб вони працювали на максимальний потенціал.
Екстремальне програмування - це надзвичайно популярна (хоча і не така популярна, як Scrum) методологія, орієнтована на задоволення змін вимог клієнта. Перший проект екстремального програмування був розпочатий у березні 1996 року Кентом Беком у компанії Chrysler. У своїй книзі 1999 року « Екстремальне програмування пояснив: Отримати зміни» він детально розробив аспекти розробки програмного забезпечення.
Кент Бек також був піонером тестово-керованої розробки, яка поставила тестування використання на радарі як покращення щодо того, як було зроблено тоді: написання рядків і рядків коду, а потім тестування. Він також був одним з оригінальних підписантів маніфесту "Agile Manifesto", допомагаючи формувати маніфест, щоб змінити спосіб написання програм екстремального програмування.
П'ять значень Екстремального програмування на основі пояснених є:
Зв'язок
Екстремальне програмування не залежить від великої документації. Власне кажучи, екстремальна документація щодо програмування пропонується лише за потреби. Таким чином, методологія значною мірою покладається на спілкування між членами команди, а також з користувачами.
Простота
Це в основі екстремального програмування. Методологія надає перевагу простим конструкціям, не замислюючись надто вперед у майбутньому, але орієнтуючись на вимоги сьогодення, роблячи саму програму достатньо надійною, щоб додати вимоги, які майбутнє висуває.
Відгуки
Цей важливий цикл повернення вперед та назад відрізняє Agile системи в цілому та Extreme Programming зокрема від інших методологій управління програмними проектами. Постійний зворотний зв'язок може працювати різними способами, але всі вони працюють над тим, щоб зробити систему міцнішою та надійнішою.
Відгуки можуть бути різними:
- З самої Програми: Код енергійно перевіряється протягом усього циклу розробки проекту, щоб розробники могли впровадити зміни.
- Від клієнта: Це важлива частина більшості Agile систем. Клієнти пишуть тести прийняття, на яких базується розробка, і це становить основу процесу розробки. Усі ітерації також доставляються клієнтові для періодичного зворотного зв'язку.
- Від команди: Після створення нового випадку / історії використання команда негайно повертається до оцінки витрат і часової шкали, підсилюючи вимоги по мірі їх виникнення. У програмі Екстремального програмування ніхто не володіє жодним кодом, а отже, в межах груп екстремальних програмувань заохочується зворотний зв'язок щодо коду інших.
Мужність
Це може здатися дивним значенням у екстремальному програмуванні для розробки програмного забезпечення, більше підходить для чогось на кшталт армії чи морських піхотинців! Однак подумайте над цим: програмні проекти вже давно заминуті традиційними методами екстремального програмування; забезпечити комфорт обширної документації та ієрархії, що не дозволяє інноваціям. Це значення є ядром екстремального програмування: будьте готові до стрибків, без парашута, якщо справа дойде до цього! Подивіться на цей інший стиль управління проектами і будьте готові нести відповідальність, відмовитися від ієрархії та бути відповідальними та працювати, не знаючи всього на початку.
Повага
Повага, п'ята цінність, була додана пізніше і означає повагу до інших та до себе. Це також передбачає повагу до написаного коду та до очікувань та потреб клієнта. Ця цінність також лежить в основі спілкування між різними зацікавленими сторонами.
Діяльність проекту екстремального програмування
Екстремальне програмування виділяє чотири прості дії проекту. Вони є:
- Кодування : Екстремальне програмування вважає це найважливішим видом діяльності. "Без коду нічого немає", - говорить Кент Бек, засновник програми Extreme Programming.
- Тестування : Код - це лише те, що не перевірено. Екстремальне програмування є нав'язливим щодо тестування, використовуючи одиничні тести для підтвердження того, що код працює, і тести прийняття, створені клієнтом, щоб підтвердити, що код тестує те, що потрібно перевірити.
- Прослуховування: Прослуховування, що пояснюється основною цінністю спілкування, - це діяльність, яка вимагає від розробників не просто чути клієнтів, а справді слухати те, що вони хочуть. Розвиток та бізнес - це дві різні речі, і часто розробники не розуміють ділового випадку конкретного рішення. Потреби замовника, а також розробники складають основу діяльності «прослуховування».
- Проектування : Можливо, ви здивуєте, що в проекті розробки програмного забезпечення проектна діяльність, часто така важлива і основна, ставиться в кінці. Це тому, що Екстремальне програмування навмисно хоче вивести людей із «проектування та розвитку» мислення, яке галузь плекає протягом багатьох років. Це не обмежувати важливості проектування. Швидше за все, хороший і мінімальний дизайн є однією з ознак проекту.
З цінностей та діяльності випливає 12 принципів Екстремального програмування, розроблених його засновником, у своїй книзі «Екстремальне програмування».
- Планова гра
- Парне програмування
- Тест-керований розвиток
- Ціла команда
- Постійна інтеграція
- Вдосконалення дизайну
- Невеликі випуски
- Стандарти кодування
- Право власності на колективний код
- Простий дизайн
- Системна метафора
- Стійкий темп
Деякі з цих екстремальних методів програмування, всі зведені до найкращих практик програмного забезпечення, відрізняються від загальних методів Agile. Деякі з практик екстремального програмування пояснюються нижче:
-
Планова гра
Це планувальна частина проекту, яка називається «Гра планування». Він включає планування наступної ітерації та випуску за консультацією з користувачем / клієнтом, а також внутрішнє планування команд щодо завдань, над якими вони працюватимуть.
-
Парне програмування
Це стосується двох людей, які працюють над фрагментом коду. Одна людина, яку називають клавіатурою, вводить код, а інша, яка називається монітором, контролює код, коментуючи та уточнюючи його, оскільки це може виникнути потреба. Двоє людей часто обмінюються своїми ролями. Доведено, що це значно підвищує ефективність коду. Це може не підходити до всіх сценаріїв розвитку, і це те, що варто враховувати перед підпискою на програму екстремального програмування.
-
Тест-орієнтований розвиток
Весь написаний код перевіряється одинично, тобто кожен фрагмент коду, який може щось зробити, спочатку перевіряється. Екстремальне програмування робить великий акцент на тестуванні. Це допомагає підтвердити, що код працює, і щоб потім його можна було врахувати для включення в сам проект екстремального програмування. Це аналогічно одиничним тестам у школі: перевірені невеликі фрагменти інформації, щоб викладач / учень міг вносити корективи в курс і не розлетітися під час щорічних іспитів!
-
Покращення дизайну (рефакторинг)
Проекти XP, засновані на його особливості простоти, мають на меті постійно вдосконалювати написаний код. Це означає, що весь код (а іноді і база даних) завжди покращується. Рефакторинг не додає жодної функціональності; він просто покращує існуючий код. Робить це жорсткішим і чіткішим. Це схоже на редагування твору, полірування його та вдосконалення.
-
Простий дизайн
В екстремальному програмуванні функції не додаються, поки конкретно не потрібно. Навіть якщо код, над яким працює, в даний час дуже схожий на те, що може знадобитися в майбутньому, він не приймається, якщо не буде узгоджено як історія користувача.
-
Системна метафора
Сюди входить стандартизація всіх конвенцій про іменування, щоб їх мета та функції легко розшифровувалися. Наприклад, або операції можуть допомогти будь-якому програмісту зрозуміти їх функціональність. Це слід робити у всьому проекті екстремального програмування, щоб хтось легко міг переглянути код і змінити або покращити його, залежно від випадку.
Ролі в рамках проекту екстремального програмування:
Як і Scrum, Extreme Programming має кілька визначених ролей у кожному проекті. Тепер ролі не завжди повинні виконувати різні люди, і людина може взяти на себе більше, ніж одну роль.
Екстремальні програми програмування:
- Замовник : роз'яснення. Причина проекту. Вона вирішує, що проект повинен зробити. Вона надає розповіді користувачів.
- Програміст : Це людина, яка:
- Візьме розповіді, які придумує замовник
- Створює завдання програмування з розповідей
- Реалізує розповіді користувачів
- Тестує код за одиницею
- Тренер : Тренер, як правило, гарантує, що проект іде на шляху, а також прискакає, щоб допомогти, коли потрібно.
- Tracker : Tracker здійснює конкретні запити до програмістів через встановлений інтервал. Зазвичай він обходить перевірку прогресу програмістів, пропонуючи допомогу там, де це потрібно декількома способами: закручуючи рукави та допомагаючи безпосередньо з кодом, повідомляючи Тренера або налаштовуючи зустріч із замовником, як це можливо.
- Тестер : виконує функціональні тести. Тестер не виконує одиничні тести, які виконуються самими програмістами.
- Doomsayer: Це, як випливає з назви, схоже на Чорну Шапочку в системі групового мислення Едварда Де Боно. Будь-хто може бути Судом, який, як правило, відзначає потенційні проблеми та допомагає тримати проблеми у правильній перспективі.
- Менеджер : Менеджер у програмі екстремального програмування більше нагадує планувальник, гарантуючи, що зустрічі відбуваються відповідно до запланованих, а також рішення, прийняті під час зустрічей, передаються відповідній особі, частіше за все, трекеру. Менеджер, однак, не говорить людям, що робити і коли це робити. Це робиться самим Замовником та / або Історіями користувачів.
- Власник золота : власник золота - це людина, яка фінансує проект. Це може бути замовник, але не обов’язково.
Деякі екстремальні програми програмування, як описано вище, можна поєднувати, але деякі явно не можуть.
Клієнт, наприклад, також не може бути програмістом. Програміст і відслідковувач, так само не можуть бути успішною людиною.
Екстремальні ролі програмування визначені досить чітко, щоб не було плутанини, і створені для досягнення максимальної гнучкості та ефективності.
Недоліки екстремального програмування:
Хоча прихильники програми Екстремального програмування малюють райдужну картину, факт полягає в тому, що програмування "Екстремальне", як видно з назви, надзвичайно складно реалізувати. Грані екстремального програмування можуть бути включені до проектів успішніше, ніж повністю прийняття XP.
Деякі з негативів Екстремального програмування:
- Екстремальне програмування виявляється більш ефективним у менших групах . Його ефективність у більших групах оспорюється, і кращим варіантом є розділення команд екстремальних програмувань, щоб групи були меншими.
- Однією з ключових особливостей Екстремального програмування є парне програмування не дуже добре в багатьох випадках . Складне кодування може зажадати двох голів, але не у всіх завданнях можуть знадобитися дві людини, при цьому друга людина має мертву вагу. Насправді, парне програмування, якщо один з членів не синхронізується з іншим, є однією з головних причин, чому Екстремальне програмування в багатьох випадках виходить з ладу.
- Залежність від замовника, до того, що дозволяє запропонувати ресурс на місці з боку замовника, може бути глибоко неприємним. Це також може призвести до втручання, як реального, так і уявного під час розвитку.
- Зосередженість екстремального програмування на простоті може ускладнити додавання до поточного проекту, що означає більш високий бюджет навіть для простих змін, які вже не залишаються простими.
- Плоська ієрархічна структура означає, що команда повинна бути завжди зосереджена, і за відсутності керівника, який би відповідав різним типам людей, команда з екстремального програмування повністю залежить від емоційної зрілості всіх членів команди, чинника, який не завжди залежить .
Навіть з урахуванням цих факторів Екстремальне програмування залишається потужним інструментом для правильного проекту, і компанії повідомляють про багаторічне підвищення їх ефективності після прийняття екстремального процесу програмування. Система, керована розробниками, на відміну від Scrum, яка є більшою мірою процесовою системою, Екстремальне програмування або, принаймні, його частини, може призвести до революції в тому, як ми розробляємо програмне забезпечення екстремального програмування.