В нашей компании есть небольшой набор правил. Ниже приведена краткая выдержка из него.

...

2. Общепринятые правила

2.1. О взаимодействии с заказчиком

...

2.1.4. Платные или бесплатные доработки?

Обычно в мелочных мелочах мы идем навстречу клиенту. Это означает, что редкие мелкие доработки мы можем вносить бесплатно. Например, если заказчик раз в месяц попросил изменить текст надписи в каком-то окошке, то мы за это не берем денег. Деньги берутся в случае, если мелких доработок становится много, или хотя бы одна из них уже не такая мелкая.

В общем-то, вы не обязаны следовать этому правилу, и ваш труд оплачивается в любом случае, но умеренное следование данному принципу приветствуется.

2.1.5. Об уведомлении заказчика о новых фичах или исправлениях

У нас есть простые правила сообщения заказчику о новых фичах или исправлении багов. См. соответствующий раздел про TFS.

2.1.6. Пароли заказчика

Если вам доверены пароли от сервера заказчика – просьба отнестись к этому максимально серьезно и приложить все усилия, чтобы они не были скомпрометированы. Не хранить их в общепринятых местах, не пользоваться фичей «запомнить пароль», не хранить их в FTP-клиентах, проверяться на вирусы и т.п.

Утечка пароля от сервера клиента может очень сильно подпортить нашу репутацию перед заказчиком, а то и привести к финансовым последствиям.

Если заказчик не хочет давать свой пароль, то на это не стоит обижаться. Это скорее даже в плюс: у вас не будет болеть голова в случае проблем «как доказать, что это был не я». Если произошло что-то нехорошее, а заказчик знает, что пароля он вам не давал, то и подозрений на вас никаких быть не может.

...

4. Работа с TFS

...

4.3. Билды на сервере

Когда у нас стоял TFS 2010, его механизм билдов не подошел, потому что он умеет собирать только солюшен целиком, сбрасывая Output со всех проектов в одну кучу. Написали свой. Может быть TFS 2013 в этом плане лучше, но уже поздно :)

Вообще параметры сборки для каждого проекта настраиваются индивидуально, но в целом сборка делается после каждого чекина – как минимум для того, чтобы отследить факт ее поломки.

Варианты донесения новой версии заказчику бывают разные:

• В ряде случаев TFS делает билд, скриптом запаковывает его и выкладывает в виде ссылки на архив с новой версией программы. Эта ссылка отсылается заказчику, и тот сам у себя разворачивает новую версию. Вам здесь делать ничего не нужно. Как правило, в таких проектах при каждом чекине задается обязательный вопрос – «Отправлять билд заказчику?». Он нужен для того, чтобы не отправлять заказчику промежуточные версии.
• В ряде случаев мы сами выкладываем обновление. Чаще всего клиентская часть приложения распространяется через ClickOnce, который также развернут на нашем сервере, а серверную часть мы обновляем вручную, зайдя на сервер заказчика. Разумеется, если в вашем проекте используется этот способ, то после выкладки обновления вы должны кратко протестировать его работоспособность.

В любом случае у нас принято правило: в видимой части приложения (толстый клиент или веб-сайт) мы показываем номер версии и дату ее сборки. Версия нумеруется по правилам MS, и последняя цифра – это номер чекина. Т.е., например, 1.0.0.7218. Номер версии и дату сборки TFS подставит самостоятельно.

...

5. Технические частности

...

5.8. Иконка приложения

Никогда не оставляйте стандартную иконку у разрабатываемого приложения. Речь об иконке самого exe-файла и иконке в заголовке окна. Если вам не выдали иконку персонально для этого проекта, то возьмите сами любую, подходящую под тематику заказчика, вот отсюда:
https://www.iconfinder.com/
http://findicons.com/

...

7. Крайне рекомендуемые книги по нашей тематике

• «Дизайн привычных вещей» (Дональд Норман). Эта книга – об интерфейсах. Она не содержит никаких конкретных советов и рекомендаций, но очень хорошо промывает мозг на тему «как делать понятные интерфейсы», задавая правильный настрой.
• «Дизайн для недизайнеров» (Робин Вильямс). В отличие от предыдущей книги, здесь конкретные рекомендации по оформлению внешнего вида чего-либо. Вам достаточно прочитать главы 1-6.
• «Джоэль о программировании» (Джоэль Спольски). Musthave для любого разработчика.
• «И снова о программировании» (Джоэль Спольски). Продолжение. Немного более отвлеченно и пафосно, но все равно стоит прочитать.
• «Бизнес для программистов» (Эрик Синк). В книге много полезных практических советов, которые имеют отношение скорее к разработке, чем к бизнесу. Крайне рекомендуется к прочтению.