Як ви знаєте, коли припинити додавати функції?

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

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

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

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

Звідки ви знаєте, коли потрібно припинити додавати / налаштовувати / виправляти речі та дозволяти дитині повзати на відкритому повітрі?

Коли ви досягнете терміну.

Якщо у вас немає строку, це ваша проблема ...

Ось як я працюю:

1. Я додаю нові функції / помилки в своє відставання продукту.
2. Я розставляю пріоритет усього продуктового відставання за вартістю бізнесу та кошторисом (останній є необов’язковим у випадку персонального проекту).
3. Я виділяю робочий час на себе. Дата виходу - кінець цього часу.
4. Я починаю з самого першого в списку. Я працюю над функцією час. Щоб завершити, функція повинна бути дійсно повною, включаючи документацію (наприкінці функції я потенційно можу відправити продукт).
5. Наступний я приймаю, поки не буде витрачений мій відведений час.
6. Якщо витрачається час, коли я будую функцію, я її тимчасово відкидаю.
7. Коли витрачений час буде витрачений, я беру останню збірку і роблю реліз із нею.
8. Я повторюю процес з пункту 1.

Зробіть тоді SRS- код відповідно до вимог. Коли ви досягли всіх цілей, зазначених у СРС, прийшов час зупинитись і протестувати свій продукт.

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

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

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

Ви завжди можете годувати проект на віки віків.

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

Це залежить від того, чому ви додаєте функції. Чи запитують його власники проектів? користувачів? QA? Програмісти?

• Додайте необхідні функції.
• Просійте важливі функції.
• Ігноруйте функції, які приємно мати.

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

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

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

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

В кінці тижня відпустіть його. Відпускайте достроково, випускайте часто.

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