Замовник

Людина або група людей, зацікавлених в створенні конкретного програмного продукту. Він має наступні має рацію і обов'язки:

• зафіксувати терміни випуску версій продукту;

• приймати вирішення щодо запланованих складових програми;

• знати орієнтовну вартість кожної функціональної складової;

• приймати важливі бізнес рішення;

• знати поточний стан системи;

• змінювати вимоги до системи, коли це дійсно важливо.

Для успішного використання своїх прав замовник повинен вважатися на дані, що надаються розробниками.

Укладач історій – фахівець наочної області, що володіє здібностями доступно викласти і описати вимоги до системи, що розробляється. Ця людина або група людей відповідальні за написання історій користувача і прояснення нерозуміння з боку програмістів.

Приймальник – людина, контролююча правильність функціонування системи. Добре володіє наочною областю. У обов'язки входить написання приймальних тестів.

Великий бос – стежить за роботою всіх ланок, від розробників до кінцевих користувачів. Він контролює впровадження системи і супутні організаційні моменти. Може бути також інвестором проекту.

Розробник

Один або група від двох до десяти чоловік, що займаються безпосередньо програмуванням і супутніми інженерними питаннями. Розробник наділений наступними правами і обов'язками:

• отримати достатнє знання питань, які повинні бути запрограмовані;

• мати можливість з'ясування деталей в процесі розробки;

• надавати орієнтовні, але відверті оцінки трудовитрат на кожну функціональну частину або історію користувача;

• коректувати оцінки точніших в процесі розробки;

• надавати оцінку рисок, зв'язаних з використанням конкретних технологій.

Програміст – людина, що займається кодуванням і проектуванням на низькому рівні. Він достатньо компетентний для вирішення поточних завдань розробки і надання правдивих оцінок запланованим завданням.

Інструктор – досвідчений розробник, що добре володіє всім процесом розробки і його методиками. Несе відповідальність за навчання команди аспектам процесу розробки. Упроваджує і контролює правильність виконання методик використовуваного процесу. Звертає увагу команди на важливих, але по якихось причинах упущені моменти розробки..

Спостерігач – член команди розробників, що користується довірою всієї групи, який стежить за прогресом розробки. Він порівнює попередні оцінки трудовитрат і реально витрачені, виводячи кількісні показники роботи команди. Дана інформація надається замовникові для своєчасного контролю над ситуацією.

Дипломат – комунікабельна особа, що ініціює спілкування між членами команди. Дипломат регулює і спрощує спілкування між замовниками і розробниками. Є важливою ланкою на зборах.

Зовнішні ролі

Консультант – фахівець, що володіє конкретними технічними навиками, для допомоги розробникам у важко вирішуваних завданнях. Зазвичай притягується з боку.

Правила Екстремального Програмування

Угода про кодування

Ви в команді, яка працює над даним проектом тривалий час. Люди приходять і йдуть. Ніхто не кодує поодинці і код належить всім. Завжди будуть моменти, коли необхідно буде зрозуміти і скоректувати чужий код.

Отже, всі повинно підкорятися загальним стандартам кодування – форматування коду, іменування класів, змінних, констант, стиль коментарів.

Колективне володіння кодом

Коллективное владение кодом стимулирует разработчиков подавать идеи для всех частей проекта, а не только для своих модулей. Любой разработчик может изменять любой код для расширения функциональности, исправления ошибок или рефакторинга.

CRC Сесія

Використовуйте Class, Responsibilities, Collaboration (CRC - Клас, Обов'язки, Взаємодія) картки для дизайну системи командою. Використання карток дозволяє легше привчитися мислити об'єктами, а не функціями і процедурами. Також картки дозволяють більшій кількості людей брати участь в процесі дизайну, а ніж більше людей робить дизайн, тим більше цікавих ідей буде привнесено.

Кожна CRC картка є екземпляром об'єкту. CRC сесія відбувається так: кожен з учасників відтворює систему кажучи які повідомлення він шле яким об'єктам. Проходить по всьому процесу повідомлення за повідомленням. Слабкі місця і проблеми відразу виявляються. Альтернативи дизайну також добре видно при симуляції процесу.

Замовник

Одна з вимог XP – замовник завжди доступний. Він винен не просто допомагати команді розробників, а бути її членом. Всі фази XP проекту вимагають комунікації із замовником, краще всього лицем до лиця – на місці. Краще всього, просто призначити одного або декількох замовників в команду розробників.

User Stories пишуться замовником за допомогою розробників. Замовник допомагає упевнитися, що більшість бажаних функцій системи покрита User Story.

У час планування релиза замовникові необхідно обговорити вибір User Stories які будуть включені в планований релиз. Також, можливо, потрібно буде погоджувати період самого релиза. Замовник ухвалює рішення що відносяться до цілей бізнесу.

Вибирайте найпростіше рішення

Простий дизайн завжди легко реалізувати, чим складний. Тому завжди робіть просте рішення, яке може працювати..

Рефакторіть чужий код якщо він здається вам складним. Якщо щось виглядає складним – це вірна ознака проблеми в коді.

Зберігайте рішення наскільки можливо простими якомога довше. Ніколи не додайте функціональність на майбутнє – до того як з'являється в ній необхідність.

Функціональні тести

Приймальні тести пишуться на основі User Story. Вони розглядають систему як чорний ящик. Замовник відповідальний за перевірку коректності функціональних тестів. Ці тести використовуються для перевірки працездатності системи перед випуском її у виробництво..

Часта інтеграція

Разработчики, по возможности, должны интегрировать и выпускать свой код каждые несколько часов. В любом случае никогда нельзя держать изменения дольше одного дня. Каждая пара разработчиков должна отдавать свой код, как только для этого появляется разумная возможность. Это может быть когда все UnitTest-ы проходят на 100%.

Планування Ітерації

Iteration Planning Meeting скликається перед початком кожної ітерації для планування завдань які будуть зроблені в цій ітерації. Для ітерації вибираються User Storiesякі вибрав замовник в плане релизу починаючи з найважливіших для замовника і найгірших (зв'язаних з ризиком) для розробників.

Розробники розбирають завдання і оцінюють тривалість часу, необхідного для їх виконання. Таким чином, кожен розробник оцінює скільки часу завдання займе саме у нього. Це важливо, щоб кінцеву оцінку об'єму робіт робив сам розробник.

Швидкість проекту визначає чи поміщаються ваші завдання в ітерацію чи ні. Загальна тривалість завдань запланованих на ітерацію не повинна перевищувати швидкості, досягнутої в попередній ітерації..

Ітерації

Ітеративна розробка збільшує гнучкість процесу. Розділите ваш план на ітерації тривалістю від 2 до 3 тижнів. Зберігайте постійну тривалість ітерації на час проекту.

Не плануйте завдань заздалегідь. Замість цього збирайте Плануввання Ітерації на початку кожної ітерації щоб запланувати що буде зроблене.

Сприймайте серйозно терміни завершення ітерації. Вимірюйте прогрес в процесі роботи. Якщо видно, що ви не зможете зробити всі заплановані завдання до терміну, то знову збирайте Планування Ітерації і оціните завдання наново і відкладете частину завдань.

Сконцентруйте зусилля на завершенні найважливіших завдань, вибраних Замовником замість того щоб мати декілька незавершених завдань, вибраних розробником.

Міняйтеся завданнями

Необходимо периодически менять задачи у разработчиков для уменьшения риска концентрации знаний и узких мест в коде. Если только один человек в вашей команде может работать в данной области и этот человек уходит или вам просто надо много всего сделать в данном сегменте программы, вы обнаружите что ваш проект еле-еле продвигается вперед.

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

Така практика також стимулює появу нових ідей і поліпшення коду.

Залишайте оптимізацію на потім

Ніколи не оптимізуйте нічого до закінчення кодування. Ніколи не намагайтеся вгадати де будуть вузькі місця по продуктивності.

Зробіть щоб це працювало, потім щоб працювало правильно, потім щоб працювало швидко.

Парне програмування

Весь код для продукційної системи пишеться парами. Діє принцип "Одна голова добре, а дві краще". Пари зазвичай знаходять більш оптимальні рішення. Крім того істотно збільшується якість коду, знижується число помилок і прискорюється обмін знаннями між розробниками.

Безжально Рефакторіть!

Програмісти, схильні триматися за дизайн довго після того, як він стає незграбним; продовжують повторно використовувати незручний в супроводі код, оскільки він все ще якось працює Коли ми прибираємо надмірність, покращуємо застарілий дизайн прибираємо невживані шматки – ми робимо рефакторинг. Рефакторінг зрештою економить час і покращує якість продукту.

Безжально переглядайте будь-який код для того, щоб зберегти дизайн простим у процесі розробки. Зберігайте код ясним і зрозумілим щоб його було легко зрозуміти, модифікувати і розширювати. Упевніться що все написано один і лише один раз. Зрештою, це займає менше часу чим доводити до пуття заплутану систему.

План Реліза

План Реліза розробляється на зборах по плануванню Реліза. Реліз Плани описують погляд на весь проект і використовуються надалі для планування ітерацій.

Важливо, щоб технічні люди робили технічні рішення і люди бізнесу – бізнес рішення. Планування Реліза визначає набір правив, які дозволяють всім ухвалювати свої рішення. Ці правила визначають метод вироблення що задовольняє всіх плану робіт.

Реліз можна планувати за часом або за об'ємом. Для того, щоб визначити скільки User Stories можуть бути реалізовані до конкретної дати або скільки реального часу займе даний набір завдань використовують швидкість проекту.

Часті Релізи

Розробники повинні випускати версії системи користувачам (або бета-тестерам) якомога частіше.

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

Пробне рішення

Створюйте пробні рішення для відповіді на складні технічні питання, для обгрунтування тих або інших технологічних рішень. При ухваленні будь-якого технологічного рішення існує ризик і пробні рішення покликані зменшити його.

Зробіть програму, яка відтворює досліджувану проблему і ігнорує все останнє.

Збори стоячи

Кожен ранок проводяться збори для обговорення проблем, їх рішень і для посилення концентрації команди. Збори проводяться стоячи для уникнення тривалих дискусій не интересных всім членам команди.

Якщо у вас проводяться щоденні збори стоячи, то решта всіх зборів повинна відвідувати тільки ті люди, які необхідні і що-небудь привноситимуть. Більш того, є можливість навіть уникнути деяких зборів. З обмеженням учасників, більшість зборів можуть бути проведене спонтанно перед монітором, де обмін ідеями набагато інтенсивніший.

Щоденні уранішні збори це не ще одна витрата часу. Воно дозволить вам уникнути багатьох інших зборів і заощадить більше часу, чим на нього витрачено.

Метафора Системи

Завжди вибирайте System Metaphor – просту і зрозумілу концепцію щоб члени команди називали всі речі однаковими іменами. Для розуміння системи і виключення дублюючого коду надзвичайно важливо як ви називаєте об'єкти. Якщо ви можете припустити як називається який-небудь об'єкт в системі (якщо ви знаєте що він робить) і він правда так називається – ви збережете силу-силенну часу і сил.

Unit Test-и

Unit тесты играют ключевую роль в XP. Они позволяют быстро менять код, не боясь наделать новых ошибок. Unit тест пишется для каждого класса, тест должен проверять все аспекты работы класса – тестировать все что может не работать.

Unit тест для класу зберігається в загальному репозиторії разом з кодом класу. Ніякий код не може бути випущений без Unit тесту. Перед віддачею коду розробник повинен упевнитися, що всі тести проходять без помилок. Ніхто не може віддати код, якщо все не пройшли 100%.

Unit тести дозволяють здійснити колективне володіння кодом. Вони дозволяють відносно легко переглядати поганий код. Також Unit тести дозволяють у будь-який момент мати стабільно працюючу систему.

User Story

User Story – це опис того, як система повинна працювати. Кожна User Story написана на картці і представляє якийсь шматок функціональності системи, що має логічний сенс з погляду Замовника. Форма – один-два абзацу тексту зрозумілого користувачеві (не сильно технічного).

User Story пишеться Замовником. Вони схожі на сценарії використання системи, але не обмежуються призначеним для користувача інтерфейсом. По кожній історії пишуться функціональні тести, підтверджуючі що дана історія коректно реалізована, – їх ще називають приймальними (Acceptance tests).

Кожній User Story дається пріоритет з боку бізнесу (користувач, замовник, відділ маркетингу) і оцінка часу виконання з боку розробників. Кожна історія розбивається на завдання і їй призначається час коли її почнуть реалізовувати.

Швидкість проекту

Швидкість Проекту це міра того, як швидко виконується робота у вашому проекті.

Щоб зміряти швидкість проекту, ви просто повинні порахувати об'єм User Stories або як багато (за часом) завдань було виконано за ітерацію. Просто порахуйте сумарний час оцінки об'єму роботи (ідеальний час).

Під час планування релиза швидкість проекту використовується для оцінки того скільки User Stories може бути зроблено.

Під час планування ітерації, швидкість проекту в попередній ітерації використовується для визначення того скільки User Stories треба планувати в поточну ітерацію.

Коли виявлена помилка

Якщо виявляється помилка, то створюється тест, щоб запобігти її повторній появі. Помилка, що відбулася в робочій системі (вже встановленою), вимагає написання функционального тесту. Створення функціонального тесту безпосередньо перед діагностикою помилки дозволяє замовникам чітко описати проблему і довести цю проблему до розробників.

Вам це не знадобиться

Утримаєтеся від заповнення системи речами, які знадобляться вам в майбутньому. Тільки 10% від очікуваного дійсно знадобиться вам в первинному вигляді, тобто 90% вашого часу буде витрачено даремно.