每个公司都有自己的产品开发规范，我自己也大概想了下，比较适合小团队。
借鉴 Unix 的设计哲学：一个工具只做好一件事，并提供接口。放到产品开发就是：产品可以被划分成多个模块，每个模块都有相应的 API。这样就能做到分工明确和解耦。
三层架构
表现层
web / mobile / app …
API 层
user / article / comment / …
基础服务层
db / queue / memcache / …
如果使用 GAE 的话，就不用花心思去构建基础服务层了。这样就只剩下表现层和 API 层。
分工
每个人都要负责产品的一部分，有两种构建方式：水平构建和垂直构建
垂直构建
假如我负责用户系统，则所有与用户相关的事情都由我来完成，从前端到后端，包括 API，页面展示，互动等等。这样做的话，对开发人员的要求比较高，需要同时对前后台都比较熟悉。但能减少沟通成本，提高开发效率。假如用户系统出现了一个 bug，我就能很快地修复，因为我最熟悉，且所有与用户相关的都由我负责。
水平构建
这也是大部分公司采用的方法，把开发人员分为前端/后端等等。前端的任务就是负责页面的展示和交互，后端开发人员负责 API 的构建，可能还会有专门的 DBA。这样做的好处是可以发挥每个人的特长。但也有不少问题，比如用户系统出现了一个 bug，前端相信自己的程序没有问题，就会把问题推给后端，后端查看了一遍也觉得没问题，可能又会把问题推回去。这样一来二去，不仅浪费时间，影响效率，还会破坏团队的氛围。
假如又有了一项新任务，是开发一个评论系统，前端可能 1 天就把页面做完了，然后就干别的事去了，结果后端花了 4 天才把 API 搞定。然后前端又要从别的地方把心收回来，阅读 API 文档，再整合，又耽搁了不少时间。这就有点不够敏捷了。
项目管理
我推荐使用 Basecamp+Campfire+github。Basecamp 用来管理项目；Campfire 是团队讨论的地方(已与 Basecamp 集成)，可以开设多个版块；github 用来管理源码。
一个高效的开发者最不能接受的就是被打断，我好不容易进入了状态，结果被迫去跟你讨论一个不太重要的问题，这简直是谋杀，所以开发项目时最好把 IM 关掉，或者设置成离开状态。
dropbox 可以作为辅助工具，用来在团队内部共享资料。
github 的开发流程，可以参考此文
Tips
- frontController 要尽可能的薄，通常只需负责渲染页面
- 使用hmvc将各个页面模块组合成一个页面
- 可以使用内部 REST 的方式来合并多个 REST 请求
- API 层可以模拟 http 的 403 状态码来减少数据传输
暂时就想到这些了，实际情况肯定要复杂地多。有哪些地方可以改进，或者根本就不现实，欢迎指出 :)