Несколько друзей на работе и я собираемся создать небольшой стартап / создать собственное программное обеспечение, вероятно, поначалу подрабатывающее луной, так как мы еще не можем позволить себе бросить нашу повседневную работу.
Ни у кого из нас нет такого опыта, мы все работали в других компаниях раньше, где был установлен набор руководящих принципов, и я думаю, что сейчас самое время выработать передовые методы, которым нужно следовать (например, избегать встреч с участниками).
Для людей, которые пошли этим путем, какой совет (ы) вы бы дали нам?
Я больше ищу техническую сторону вещей, таких как:
Стоит ли иметь какой-то сервер сборки или это будет далеко впереди?
Вы бы сделали расширенный TDD или думаете, что это будет слишком много для небольшой команды, которая не слишком опытна в этом?
Но не прочь выслушать управленческую сторону вещей.
Проект представляет собой веб-приложение, выполненное в ASP.NET MVC, я думаю об использовании Mercurial и BitBucket или Kiln + FogBugz или какого-либо другого онлайн-инструмента отслеживания проектов, поскольку мы собираемся работать удаленно.
источник
3часть - нецелесообразно / нецелесообразно ставить произвольный предел того, сколько людей следует предлагать (и, вероятно, большинство людей в любом случае проигнорируют это).Ответы:
Выпустите как можно быстрее . Скорее всего, 90% кода, с которого вы начинаете, не дойдут до конца первых 6 месяцев. Так что нет смысла проектировать его как сумасшедшего. Кодируйте как можно быстрее, чтобы выйти на рынок, а затем пусть ваши пользователи решат, как его развивать дальше. Если TDD работает быстрее, используйте TDD. В противном случае просто взломать его. Ранние пользователи довольно легко прощают несколько ошибок, когда ваш продукт находится в бета-версии.
Не тратьте время на то, чтобы быть системными администраторами. У вас есть правильная идея с размещенными платформами для отслеживания ошибок (например, FogBugz) и контроля версий. Используйте онлайн-хранилище документов, такое как Google Docs . Если вы храните что-либо локально, используйте онлайн-сервис облачного резервного копирования, например, Carbonite . Если вы можете себе это позволить, арендуйте полностью управляемое решение для хостинга. Старайтесь избегать необходимости поддерживать свои собственные серверы.
Сконцентрируйтесь на том, что делает вас уникальным . Если вы обнаружите, что пишете код, который, кажется, должен был быть сделан раньше, используйте то, что уже есть. Станьте экспертами в решении вашей бизнес-проблемы и не отвлекайтесь на проблемы вне вашего домена.
источник
если команда - это больше, чем вы, стандарты имеют значение. Они не должны быть сложными («используйте значимые имена переменных, CamelCase и не нарушайте сборку»). TDD качается, потому что он работает, используйте его. Тесты, которые вы придумали, также являются отличной основой для демонстраций. Сервер сборки может быть за бортом, а может и нет; начать без одного и посмотреть, как это идет. Инструменты отслеживания также; могу добавить позже по мере необходимости.
Предполагая , что этот продукт должны быть продано, сделать некоторые исследования рынка в настоящее время , чтобы убедиться , что вы строите то , что люди на самом деле хотят. Обрисуйте бизнес-план, чтобы перейти от нуля к рынку, разделить обязанности и справедливость и привлечь друг друга к ответственности.
Удачи!
источник