• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

CRC Сесія

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

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

Замовник

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

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

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

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

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

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

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

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

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

Переглядів: 264