Створіть один, щоб викинути ефект проти другої системи

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

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

Хіба тут немає суперечності між цими принципами? Який правильний погляд на проблеми та де межа між цими двома?

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

Я знаю, що деякі з цих питань вирішуються методами Agile, але в глибині душі проблема все ще є принципами; наприклад, ми б не робили важливих змін дизайну 3 спринтами, перш ніж виходити наживо.

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

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

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

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

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

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

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

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

Вимоги Інженерія - Вимагайте бізнес-вимог (тобто фіксуйте бізнес-процеси та визначайте, які бізнес-операції мають підтримуватися комп'ютеризованою системою, перекладіть 1: 1 бізнес-операції на випадки використання системи). Перевірте та підтвердьте! (чи ми будуємо правильну річ? Чи правильно ми будуємо річ?) Усі вимоги повинні бути пов'язані з початковою потребою в бізнесі.

Дизайн програмного забезпечення - Перекладіть випадки використання та модель домену в дизайн компонентів та архітектуру рішення. Усі компоненти повинні бути пов'язані з вимогами RE.

Впровадження - Запрограмуйте програмне забезпечення, як у дизайні. Весь код повинен бути пов'язаний з компонентами з SD.

Валідація - Тестування блоку, тестування інтеграції, продуктивність, ... (всі випадки використання з RE тепер потрібно буде перевірити)

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

Перегляньте ці умови, щоб створити краще програмне забезпечення та щоб правильно його вперше:

• Аналіз техніко-економічного обґрунтування (особливо, як створити бізнес-кейс)
• Управління проектами (особливо план проекту та реєстр ризиків із зменшенням ризику)
• Вимоги інженерія (отримання, аналіз, специфікація, перевірка)
• Дизайн програмного забезпечення (інженерія програмного забезпечення на основі компонентів)
• Побудова програмного забезпечення (схеми дизайну, рамки, оборонне програмування)
• Перевірка програмного забезпечення (тестування пристрою, UAT тощо)