Ітерації

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

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

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

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

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

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

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

Збори стоячи

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

Дизайн

• Простота.

• Обов'язково вибрати Метафору системи.

• Використовувати CRC карточки для дизайну.

• Писати Пробні рішення для зменшення рисків.

• Не додавати ніяких функцій раніше часу.

• Рефакторіть безжально.

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

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

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

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

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

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

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