Buone pratiche che ogni avvio dovrebbe seguire [chiuso]

Un paio di amici al lavoro e io installeranno una piccola startup / creeranno il nostro software, probabilmente inizialmente al chiaro di luna, dato che non possiamo ancora permetterci di lasciare il nostro lavoro quotidiano.

Nessuno di noi ha questa esperienza, abbiamo già lavorato per altre società in precedenza, dove sono state fissate una serie di linee guida e penso che sia il momento di stabilire le buone pratiche da seguire (come evitare incontri-itis).

Per le persone che sono andate in questo modo, quali consigli ci daresti?

Sto cercando di più per il lato tecnico delle cose, cose come:

• Vale la pena avere un qualche tipo di server di build o sta andando molto avanti?

• Faresti un TDD approfondito o pensi che sarebbe troppo sovraccarico per un piccolo team che non ha troppa esperienza con esso?

Ma non dispiacerebbe ascoltare il lato gestionale delle cose.

Il progetto è un'applicazione Web realizzata in ASP.NET MVC, sto pensando di utilizzare Mercurial e BitBucket o Kiln + FogBugz o qualche altro strumento di monitoraggio dei progetti online, poiché lavoreremo da remoto.

1. Rilascia il più velocemente possibile . È probabile che il 90% del codice con cui inizi non supererà i primi 6 mesi. Quindi non ha senso progettarlo come un matto. Codifica il più rapidamente possibile per arrivare sul mercato, quindi lascia che i tuoi utenti decidano come svilupparlo ulteriormente. Se TDD è il modo più veloce per scrivere il codice, usa TDD. Altrimenti, basta hackerarlo. Gli utenti che adottano le versioni precedenti perdonano abbastanza alcuni bug quando il tuo prodotto è in versione beta.

2. Non perdere tempo a diventare amministratori di sistema. Hai l'idea giusta con piattaforme ospitate per il monitoraggio dei bug (ad esempio FogBugz) e il controllo del codice sorgente. Utilizzare un repository di documenti online come Google Docs . Se memorizzi qualcosa a livello locale, utilizza un servizio di backup cloud online come Carbonite . Nel tuo ambiente live, noleggia una soluzione di hosting completamente gestita se te lo puoi permettere. Cerca di evitare di dover mantenere i tuoi server.

3. Concentrati su ciò che ti rende unico . Se ti ritrovi a scrivere codice che sembra aver già fatto prima, usa ciò che è già lì. Diventa esperto nel risolvere il tuo problema aziendale e non farti distrarre da problemi esterni al tuo dominio.

se la squadra è più di te, gli standard contano. Non devono essere complicati ("usa nomi di variabili significative, CamelCase e non interrompere la build"). TDD oscilla perché funziona, usalo. I test che ti vengono in mente rappresentano anche un'ottima base per le dimostrazioni al calare di un cappello. Un server di build potrebbe essere in overboard, potrebbe non esserlo; iniziare senza uno e vedere come va. Strumenti di monitoraggio allo stesso modo; può aggiungere in seguito, se necessario.

Supponendo che questo prodotto debba essere venduto, fai alcune ricerche di mercato ora , per assicurarti di costruire qualcosa che le persone vogliono davvero. Delinea un piano aziendale per passare da zero al mercato, dividere le responsabilità e l'equità e ritenersi reciprocamente responsabili.

In bocca al lupo!