Файл: Лекція 7 у оп Екстремальне програмування.doc

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

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

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

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

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

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

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

Збори стоячи

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

Дизайн

Простота.
Обов'язково вибрати Метафору системи.
Використовувати CRC карточки для дизайну.
Писати Пробні рішення для зменшення рисків.
Не додавати ніяких функцій раніше часу.
Рефакторіть безжально.

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

"Ускладнювати - просто, спрощувати - складно" Народна мудрість

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

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

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

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

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

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

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

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

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

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

Рефакторинг зрештою економить час і покращує якість продукту.

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

Кодування

Замовник завжди поряд.
Весь код повинен відповідати прийнятому стандарту.
Весь код повинен бути створений парним програмуванням.
Часта інтеграція коду.
Колективне владіння кодом.
Залишати оптимізацію на потім.

Замовник

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

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

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

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

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

Отже, всі повинно підкорятися загальним стандартам кодування - форматування коди, іменування класів, змінних, констант, стиль коментарів. Всі члени команди повинні домовитися про загальні стандарти кодування. Неважливо яких. Правило полягає в тому, що всі їм підкоряються. Ті, хто не бажає їх дотримувати покидає команду.

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

Весь код для системи (а це означає за винятком пробних рішень) пишеться парами. Два розробники сидять поряд. Один набирає, інший дивиться. Час від часу вони міняються. Не дозволяється працювати поодинці. Якщо з якоїсь причини другої з пари пропустив щось (хворів, відходив і тому подібне) він зобов'язаний проглянути всі зміни зроблені першим.

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

Розробники, по-можливості, повинні інтегрувати і випускати свій код кожні декілька годин. Кожна пара розробників повинна віддавати свій код як тільки для цього з'являється розумна можливість. Це може бути коли всі UnitTest-и проходять на 100%.

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

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

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

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

Тестування

Будь-який код повинен мати Unit Test.
Всі Unit тести повинні проходити перед віддачею.

Функціональні тести періодично виконуються і їх результати публікуються.

Unit Test-и

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

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

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

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

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

Питання:

Основні принципи "живої" розробки ПЗ.
Схема потоку робіт в XP
Переваги та недоліки XP.
Основні правила Екстремального Програмування: планування
Основні правила Екстремального Програмування: дизайн
Основні правила Екстремального Програмування: тестування

Література:

Левин В.И .История информационных технологий. Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру », БИНОМ. Лаборатория знаний ». Серия: Основы информационных технологий », 2007 - 336 стр.
Галатенко В.А., Основы информационной безопасности. Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру » Серия: Основы информационных технологий »,2008 - 208 стр.
Терехов А.Н. Технология программирования, БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2007
Скопин И.Н. Интернет-университет информационных технологий - ИНТУИТ.ру, 2004
Котляров В.П. Основы тестирования программного обеспечения. Интернет-университет информационных технологий - ИНТУИТ.ру, 2006
Микеле Марчези Экстремальное программирование - 2.0
Дэвид Астелс, Гранвилл Миллер, Мирослав Новак Практическое руководство по экстремальному программированию