Чи варто створити повнофункціональний додаток або голі кістки, а потім повільно додавати функції?

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

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

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

Що стосується того, що речі стають безладними, коли ви додаєте до оригінальної програми: ну ось чому Agile (і більшість подібних методологій) роблять великий акцент на тестуванні та рефакторингу. Рефакторинг означає очищення коду під час внесення змін, а міцний тестовий набір (який ви запускаєте щоразу, коли вносите зміни) гарантує, що якщо / коли ви вводите помилки, ви про них знаєте (майже) негайно, так що коли ви щось випускаєте до ваші користувачі ви маєте обґрунтовану впевненість, що це насправді працює.

Чи маєте ви уявлення, чи серйозно вони ставляться до програми, можливо, ви не хочете створювати рамки тощо тощо.

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

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

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

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

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

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

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

З особистого досвіду: складіть свій MVP (Мінімальний життєздатний продукт), а потім додайте до нього функції на основі отриманих вами відгуків. Легко отримати тонни функцій і не змусити їх користуватися.

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