Належні практики повинні стартувати під час кожного запуску [закрито]

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

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

Для людей, які пройшли цей шлях, який би ви поради нам дали?

Я більше шукаю технічну сторону речей, таких як:

• Чи варто мати якийсь сервер складання або це далеко вперед?

• Ви б зробили обширний TDD чи вважаєте, що це буде занадто великими накладними витратами для невеликої команди, яка не надто досвідчена з цим?

Але не проти прислухатися до управлінської сторони речей.

Проект - це веб-додаток, виконане в ASP.NET MVC, я думаю використовувати Mercurial і BitBucket або Kiln + FogBugz або якийсь інший онлайн-інструмент відстеження проектів, оскільки ми будемо працювати віддалено.

1. Відпустіть якомога швидше . Швидше за все, 90% коду, з якого ви починаєте, не змусить його пройти перші 6 місяців. Тож немає сенсу інженувати це як божевільне. Кодуйте якомога швидше, щоб потрапити на ринок, а потім дозвольте своїм користувачам вирішити, як його розвивати далі. Якщо TDD - це те, як ви швидше кодуєте, використовуйте TDD. Інакше просто зламати його. Користувачі, які користуються ранньою програмою, досить прощають кілька помилок, коли ваш продукт знаходиться в бета-версії.

2. Не витрачайте свій час, будучи сис-адмінами. Ви отримали правильну ідею з розміщеними платформами для відстеження помилок (наприклад, FogBugz) та управління джерелами. Використовуйте онлайн-сховище документів, наприклад Google Docs . Якщо ви зберігаєте що-небудь на місцях, використовуйте Інтернет-сервіс резервного копіювання хмари, такий як Carbonite . У своєму прямому середовищі зніміть повністю кероване хостинг рішення, якщо ви можете собі це дозволити. Постарайтеся прагнути підтримувати власні сервери.

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

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

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

Удачі!