关于对开发流程优化的建议详解

目录

困局

相信很多人经历的一些项目都进入过一个相同的困局：

从事软件开发多年的老兵都知道，在一个软件项目的生命周期里，不可避免地会生产很多变化（人不一定一开始就知道自己要什么，人也不一定明天要的和今天要的一样，知道自己想要什么，也是个迭代过程。此外，信息从一个大脑到另一个大脑的过程中，必然会发生丢失或改变，这也是引发变化的一个原因），这必然会导致一些返工，严重时甚至导致项目的彻底失败。虽然变化无法完全预测，但是还是存在一些方法论，能使得将变化带来的问题降到可接受的水平，甚至将快速适应变化视为团队的核心能力。这里试提出一些方法，主要从需求分析可开发流程两个方面讨论：
需求分析
从大局出发

不谋全局者不足以谋一域，需求分析的最初阶段应该从大局考虑，不要迷失于细节，需做到：

一个项目的成败与否取决于其结果是否能够满足主要干系人的期望，所以首先要搞明白主要干系人的期望是什么。比如：为什么要开发一个新系统，目的是什么果已有老系统，干系人希望新系统能够带来哪些老系统没有的东西。

然后就是对系统的整体把握，列出大致的模块划分，但是不能一视同仁地对待所有模块，应该搞清楚哪些是核心，哪些是辅助，这取决于主要干系人的期望是什么。这样在后续开发的过程中可以把精力和资源多分配在核心模块上。

最后就是术语，我觉这是软件开发中非常重要的一个因素，但是经常被忽视，以至于影响对业务的理解和团队成员之间的沟通。子曰：“名不正则言不顺，言不顺则事不成”。语言就是大脑对世界的建模，如果术语不统一，很可能会导致大家认识的偏差，比如某项目里的“后台用户”、“会员”、“内部用户”、“人员”等，鄙人觉得这几个术语看起来 很像，甚至在我们沟通的过程中时有混用，有事不免会引起一些误会。

术语定下来后，以下几个地方要务必使用：

http://www.tjjmyzs.com
详细的需求

详细的需求不必一定在开发完成之前全部做完，我觉得应该和开发保持一致，反复迭代，不断进化（下文会说到）。况且想在开始开发前就制定一份完美的详细需求是不可能的。 鄙人觉得我们的需求工作还可以从以下几点改进：
做好记录

可以简略地记录需求内容、提出者（提出着不一定是主要的干系人，需结合干系人的重要程度和功能的重要程度决定需求的优先级）、时间等，但不建议记录的非常详细（可通过口头沟通弥补细节，至于什么样的详细程度才能正好做到既能说明问题又不至于陷入文档灾难，那就是一门艺术了），起一个唤起记忆的作用就好，省的日后撕逼。
群策群力

一些关键需求尽量大家都互通一下有无，包括开发人员，测试人员和团队领导等。团队的目标是一样的，不应该把工作分的太分明，人人有份，只是大家擅长的不一样而已。比如有着丰富开发经验的程序员，也可以参与对需求的讨论，也许可以及早发现坑坑洼洼，及早填埋，需求是最关键的一环，应该群策群力，做到最好（当然，最后拍板还是需求分析师说了算，如果没有拍板人，可能会陷入无休止的争论），反倒是开发的重要性在其次，一般的业务，西二旗随随抓一个年轻人，都会写的。
分清楚方案和问题

干系人有时候会善于提出方案，不善于提出问题，而他提出的方案也许不是一个好方案，经验丰富的需求分析师或开发者应该通过方案看到问题，然后再根据问题寻找更优的方案，并说服干系人采纳。
开发流程

推荐使用敏捷开发方式，以小步快走的方式逐步发布功能，而不是一次性完成所有功能。具体方式为：

之所以要小步快跑，而不是等所有功能都做完再上线是因为一个软件系统更像是一个不断进化的生命体，而不像一个设计好图纸就可以开工的建筑物。这里有很多不确定因素，会伴随软件开发的整个过程，如：

如果采用短周期逐渐交付可运行软件系统的方法工作可以解决如下问题：

http://www.shutieba.com
总结

从更高的角度看项目的成败，其实最重要的是团队成员的士气。士气足，才可以讨论方法，士气衰，干啥都难。怎么保持士气了员工待遇，还可以考虑：