Я хочу пояснити, чому специфікацію не слід змінювати протягом періоду розробки

Я хочу пояснити, чому специфікація не повинна змінюватися протягом періоду розробки для нового працівника відділу планування.

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

Причини:

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

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

• Кінцевий тиск призводить до обрізки особливостей.

• Виявляються додаткові зацікавлені сторони до проекту (наприклад, на середині проекту аналогічний проект виявлено в іншій області, і загальні підсистеми потрібно централізувати / поділити - це сталося зі мною на середині 2-річного проекту, що призвело до значних повторних дій архітектура).

• Додаткові спонсори проекту мають нові вимоги до специфікацій (один з найвідоміших прикладів - історія розвитку транспортного засобу Bradley Fighting Vehicle).

Щодо того, чому зміни специфікацій мають несприятливий вплив (ви не можете сказати, що "не повинно відбутися", оскільки, як ви бачите, це багато причин, майже всі поза вашим контролем, і багато з вагомих причин) -

• Спеціальні зміни призводять до зміни коду, що відволікає вас від завершення деталей проекту, які ще не написані (як ми всі знаємо, і євангелізація Джоела Спольського, зміни фокусу дуже погані для розробників)

• Деякі зміни специфікацій (іноді здаються ДУЖЕ незначними) можуть призвести до необхідності повністю перепрофілювати / переробити систему, оскільки вибір між двома архітектурами був зроблений на основі припущення, взятого з специфікації .

• У випадку TDD, велика частина роботи, поставлена ​​на випробування, може бути скасована.

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

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

Те, що все це становить, звичайно, є продовженою (іноді значною) датою здачі проекту та потенційно збільшує ймовірність дефектів.

Для найкращого прикладу того, як незначна зміна специфікації може створити надзвичайні проблеми, я маю для вас 3 листи:

Y2K .

Все, що вони зробили - це змінити специфікацію, щоб сказати, " треба працювати після 2000 року ".

Крім того, в деяких ситуаціях дійсно так, що специфікація ОБОВ'ЯЗКОВО не змінюватись (на відміну від "не повинна змінюватися без поважних причин"):

• Частина специфікації - це (або залежить від) специфікація зовнішньої системи, яка повинна бути інтерфейсом.

• Частина специфікації - це (або залежить від) апаратне забезпечення, на якому реалізована система.

• Вимоги до договору з клієнтом (хоча обмеження суворо говорить про зміну специфікації без попереднього опрацювання змін із клієнтом та зміни контракту на відміну від просто факту зміни)

• Системі може знадобитися відповідати конкретним юридичним чи нормативним вимогам незалежно від переваг замовника. Приклади: шифрування кредитних карт, захист податкових даних.

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

Важливим є чітке повідомлення про наслідки змін, щоб кожен мав реалістичні очікування процесу проектування.

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

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

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

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

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

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

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

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

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