软件开发虽然有很成熟的开发模型，如CMMI，敏捷开发等，但是把整个开发流程协调好一件非常困难的事情。 项目开发过程中的细节非常重，同样是做项目，有的项目游刃有余，有的项目摸爬滚打，当然和项目困难程度有关，还有很大一部分是项目中的流程和细节做的不到位。 人是重要的因素，最近我遇到了伤心事，对着屏幕是写了一天的代码，还是发了一天的呆都是有可能的，工作的效率和一个团队的氛围也有很大的关系。
- 项目管理最重要的是做好服务：不段总结一个checklist, 在什么阶段在需要资源的时候资源已经协调好，需要工具的时候工具已准备好了。让整个项目流畅的进行。
- 确定目标做好计划：任务分配合理，分配给对的人，任务合理安排优先级。
- 在细节上形成统一：编码规范，文档模板，也包括项目的目录，文档的结构等，小到图片放的位置，流程图原图的位置，以及流程图是按照模块划分，模块内的通过标签的方式画多个图。保证团队成员可以很快找到代码和文档等。
- 发现问题持续改进：比如多人进行原型设计，需要使用axure+svn实现多人协作的版本；发布和部署麻烦，通过持续集成解决。不断提升开发效率.
- 识别风险：延期风险，依赖其他部门的风险，技术风险等，发现后，第一时间公开，然后寻找解决方案。
- 固定的节奏：站会，周例会，review，回顾会议，演示会议，启动会议，一定按照既定计划执行，养成习惯后，项目流程会执行的更好。
1 做好服务
1.1 前期准备
1.1.1 选择项目开发模型
适合项目的开发方式才是最好的。可以根据项目灵活的选择开发方式，有的项目从上到下不开发完成，无法交付测试，那这种项目可能更适合瀑布模型。
有的项目每个特性都很独立，所以敏捷开发是比较合适的，但是也不是每个Sprint都提供特性，根据需要进行调整sprint的内容也是很重要的。 分配单独的sprint进行需求分析，分配单独的sprint进行架构设计。把需求分析和架构作为每个sprint交付的内容也是一个不错的选择，毕竟没有理解好需求开发是非常危险的事情，整体的架构可能会更好，局部设计可能导致需要进行大规模的重构和返工。虽然敏捷的思想是尽早试错，但是并不代表敏捷开发没有设计，基础的设计非常重要。
1.1.2 项目目录
文档和代码是否放在同一个仓库，个人觉得需要从两点出发：除了有权限管理外，其余以开发方便为主。
- 开发人员是否可以根据开发进行文档的修改，不用公司的更高层就行评审。
- 文档的维护人员是开发人员，那放在同一个仓库是一个不错的选择。
例如：
- 如果文档不能随意修改，如需求文档，不能随意修改，变更需要走评审变更流程，那么不适合放在代码仓库。
- 概要设计文档和代码关联很大，那么放在代码仓库可以方便的修改和变更，让修改文档更方便，所以放在代码仓库也是一个不错的选择。
- 如果是创业团队，文档和代码的都是开发团队完成的，放在同一个仓库也是一个不错的选择，有人说文档修改就需要何如一次代码，其实建一个新的文档仓库也需要合入呀，还增加了维护多个仓库的成本。
例如将文档和代码放到同一个仓库的目录结构:
1
2
3
4
5
6
7
8
├─doc
├─00-项目立项
├─01-开发计划
├─02-需求分析
├─03-设计
├─04-测试
└─05-参考资料
└─src
1.1.3 准备好项目管理工具
项目任务的分解，分配和进度跟踪，需要有好的工具进行任务管理，目前比较好的方式是看板。
gitlab自带的看板，开源的看板自己搭建，还是使用免费的云平台。需要确定好，这是一起开始的前提。
1.1.4 确定项目的操作流程
- 每天站会，还是周例会，还是半周会。
- review的频率
流程是可以改变的，找到合适的节奏就要坚持，不能随性，没有规律。
2 任务管理
Making small and non-consequential decisions is fine, and makes you look like you know what you’re doing, so what a kernel manager needs to do is to turn the big and painful ones into small things where nobody really cares. –Linus
Linus的思想不仅适用于内核的开发，同样适用与普通的项目开发，将项目的需求分解为一个一个小的需求是任务分解最重要的事情。见过有人因为拿到一个大的需求，茫然懈怠的工作。
3 文档协作
文档不只决定了项目的可维护、可管理性，前期的需求，设计文档可以整理思路，设计和架构，让开发更快速，更有效。有人会说现在流行的是敏捷开发，根本不需要写文档，但其实这是对敏捷的误解。敏捷开发强调的是快速试错、快速迭代，而非简单粗暴，对比传统开发模型虽然并不强调文档，但并不代表不需要。对于一个项目，从开始就需要需求文档、产品原型文档、项目进度文档等等，而到了研发这一步，在系统实现、写代码之前最好的就是先“想”再做，而“想”的一种比较好的输出形式就是文档。
尤其对于一些相对复杂的功能来说，整理思路形成文档，不仅可以让自己逻辑清晰，也让后续维护的人能够更快地接手。当然，这些并不是死板要求的，应该根据实际的业务选择，不一定所有的文档都是必须的。
3.1 约定
3.1.1 目录结构
那个目录放图片，哪个目录放API, 哪个目录放数据库建模，那个目录放路程图。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
概要设计/
├── API --放API
│ ├── xxx-api.md --通过swagger导出的API文档
│ └── yyy-api.md
├── database-model-design --数据库建模
│ ├── device-monitor --模块
│ │ ├── device-monitor.mwb -- mysql workbench的文件
│ │ └── device-monitor.png -- 导出的关系图
│ └── report
│ ├── report.mwb
│ └── report.png
├── diagram -- 放流程图
│ ├── data-aggregation -- 模块
│ │ ├── data-aggregation.png
│ │ ├── data-aggregation.vsdx -- visio源文件，按照标签划分，一个模块一个visio文件
│ │ └── publisher.png
│ └── device-monitor
│ ├── device-monitor-0.png
│ ├── device-monitor.vsdx
├── 概要设计说明书.md -- 概要设计说明书
3.1.2 约定好文档结构
虽然已经有了文档模板，但是这个模板还无法满足多人同时写。不然后面还需要修改文档的目录编号。
- 确定模块标题
- 确定责任人
3.2 协作方式
3.2.1 设计文档：
我自己比较推崇的是使用markdown撰写文档，然后使用git、svn版本管理工具或者是其他团队协作工具做版本管理。之所以使用markdown, 能够极大地节省使用word时调各种格式、样式耗费的时间。对于程序员来说真的是如虎添翼。
3.2.2 API文档
SpringFox，使用此项目能够通过在Controller中加入相应的注解信息从而自动生成Api接口文档，同时也提供了在线调试的功能，极大减少了api文档的工作量。
3.2.3 原型协作/需求文档
团队是否确定有了原型设计，就不需要需求文档了？ 如果需要需求文档，那么需要准备好模板，确定文档格式，word还是markdown。
准备多人协作的Axure + SVN的协作环境。
3.2.4 测试用例
不要再用传统的excel表格管理测试用例，多人同时编辑excel合并就是一个噩梦。赶紧内部搭建一个testlink结束人工拷贝合并测试用例的痛苦时代吧。
3.3 文档Review
- gitlab 创建 merge request
- word 批注
- upsource
4 代码协作
编码之前需要首先确定编码规范，公司内部没有的，选择大厂的编码规范一个不错的选择。如阿里的编码规范，google的编码规范等。
准备好持续集成环境，并且自动部署，否则会被频繁编版本，发布版本耗费很多时间。同时借助代码静态检查工具进行代码静态检查，jmeter等工具进行一些初始化的工作和接口测试等等。
确定分支的管理策略，dev分支用于开发，master用于发布。所有人只能通过merge request的方式， review后才能合并代码到dev分支。修改bug创建单独的bug分支。
代码发布后打tag标签。
5 CheckList
想要整个流程管理非常的顺畅，不要遗漏，可以准备一个checklist。每一个项目都会有新的经验和感悟，以及踩过的坑。总结一个checklist是一个非常简单的方法，避免出现以前的问题。
| 阶段 | 需要内容 |
|---|---|
| 项目准备阶段 | 确定项目开发模型 |
| 项目准备阶段 | 项目管理工具 |
| 项目准备阶段 | 确定项目的例行流程 |
| 项目准备阶段 | 服务器申请，如测试服务器 |
| 项目准备阶段 | 创建文档/代码仓库，创建目录结构 |
| 需求分析 | 需求模板, 确定好文档框架，段落和标题 |
| 需求分析 | Axure + SVN多人原型工具 |
| 概要设计 | 概要设计文档模板，确定好文档框架，段落和标题 |
| 编码 | 编码规范 |
| 编码 | 持续集成环境 |
| 测试 | testLink |
6 技术提升
技术提升不属于项目管理的范围了，属于团队管理内容，但是很重要。技术的积累对团队的成长非常重要，知识的广度使得软件开发游刃有余。所以需要进行知识的分享和知识的积累，有了积累和分享后，才能让整个团队不断提高战斗力。对于个人来说，在平时的工作中，提高技术的熟练度和深度，在业余补充学习专业知识，提升技术广度，这些都无须多言。那么如何在整体层面或者说是管理上促进团队成员的技术提升呢？可以采取的方式有以下几种：
- 构建内部的技术wiki并建立技术分享机制，鼓励大家以演讲或者技术博客的方式分享自己的技术经验或者教训，既可以对自己进行review又可以给其他成员以启示。这一点，很多公司都是纳入绩效中的。
- 将一些项目开源，让团队成员能够享受到开源项目带来的各种好处，比如提升个人在业界的知名度、提高编码的水准(毕竟不好的代码，你也不好意思放出去)。
第一种方式是一定要有的，比如记录下某个开源库的使用方法，什么情况下使用，别人需要的时候直接查看文档就可以了。可以周期性安排人员进行技术分享，但是一定要注意频率不能太高，一周一次就会成为团队的负担了。慢慢形成一种氛围和习惯，再到后续鼓励大家主动分享。当然，辅以奖品激励或者绩效奖励也是一种不错的方式，但切忌不要忽视一些业务能力很强但不爱或者不善于分享的工程师。
