모든 스타트 업은 모범 사례를 따라야합니다.

직장에서 몇 명의 친구가 작은 스타트 업을 설정하고 / 우리 자신의 소프트웨어를 만들려고합니다. 아마도 처음에는 달빛을 비출 것입니다. 왜냐하면 우리는 아직 하루 일을 그만 둘 여유가 없기 때문입니다.

우리 중 어느 누구도이 경험을 가지고 있지는 않지만, 우리는 모두 가이드 라인이 설정된 이전에 다른 회사에서 근무한 적이 있습니다.

이런 식으로 간 사람들에게 어떤 조언을 해주시겠습니까?

나는 기술적 인 측면에서 더 많은 것을 찾고 있습니다.

• 어떤 종류의 빌드 서버를 가질 가치가 있습니까? 아니면 훨씬 앞서 갈까요?

• 광범위한 TDD를 수행하겠습니까, 아니면 경험이 부족한 소규모 팀에게는 너무 많은 오버 헤드가 있다고 생각하십니까?

그러나 사물의 관리 측면을 듣고 싶지는 않습니다.

이 프로젝트는 ASP.NET MVC에서 수행되는 웹 응용 프로그램입니다. Mercurial 및 BitBucket 또는 Kiln + FogBugz 또는 다른 온라인 프로젝트 추적 도구를 사용하려고 생각합니다. 원격으로 작업하기 때문입니다.

1. 가능한 빨리 릴리스하십시오 . 시작 코드의 90 %가 처음 6 개월 동안 코드를 작성하지 못할 가능성이 있습니다. 따라서 미친 것처럼 엔지니어링하는 데 아무런 의미가 없습니다. 가능한 빨리 코딩하여 시장에 진출한 다음 사용자가 추가 개발 방법을 결정하도록하십시오. TDD가 가장 빠른 코딩 방법 인 경우 TDD를 사용하십시오. 그렇지 않으면 해킹하십시오. 얼리 어답터 사용자는 제품이 베타 버전 일 때 몇 가지 버그를 용서합니다.

2. 시스템 관리자가되어 시간을 낭비하지 마십시오. 버그 추적 (예 : FogBugz) 및 소스 제어를위한 호스팅 플랫폼에 대한 올바른 아이디어가 있습니다. Google 문서 와 같은 온라인 문서 저장소를 사용하십시오 . 로컬로 무언가를 저장하는 경우 Carbonite 와 같은 온라인 클라우드 백업 서비스를 사용하십시오 . 실제 환경에서 가능한 한 완벽하게 관리되는 호스팅 솔루션을 임대하십시오. 자체 서버를 유지 관리하지 않아도됩니다.

3. 당신을 독특하게 만드는 것에 집중하십시오 . 이전에 수행했던 것처럼 보이는 코드를 작성하고 있다면 이미 존재하는 것을 사용하십시오. 비즈니스 문제를 해결하는 데 전문가가되어 도메인 외부의 문제에주의를 분산시키지 마십시오.

팀이 당신 이상이라면 표준이 중요합니다. 복잡 할 필요는 없습니다 ( "의미있는 변수 이름 CamelCase를 사용하고 빌드를 중단하지 마십시오"). TDD는 작동하기 때문에 사용합니다. 당신이 생각해 낸 테스트는 모자를 떨어 뜨릴 때 데모를위한 훌륭한 기초를 만듭니다. 빌드 서버는 오버 보드 일 수도 있고 그렇지 않을 수도 있습니다. 하나없이 시작하고 어떻게 진행되는지보십시오. 추적 도구도 마찬가지입니다. 필요에 따라 나중에 추가 할 수 있습니다.

이 제품을 판매한다고 가정하면, 지금 시장 조사를 수행 하여 사람들이 실제로 원하는 것을 만들고 있는지 확인하십시오. 제로에서 시장으로 나아가고 책임과 자본을 나누고 서로 책임을 지도록하는 사업 계획을 세우십시오.

행운을 빕니다!