软件过程管理的必要性（软件开发与过程管理项目了解）

再过5年，产品经理还有活路吗？当然有！

讲真，作为一个起初下定决心做产品的文科妹子，我始终觉得没有实业支撑和技能傍身的岗位，是十分不靠谱的。

很多人都问过一个问题：为什么会有产品经理这个职位存在？

我思索后，给出一种答案：存在即合理。

Agnes不是100%互联网基因发家的产品经理，但一直以极客精神要求自己追求本质。

也许没有人想过产品经理存在的根本原因，但是我知道最初一定起源于软件开发过程管理。

今天的PC网站和移动APP，在应用层来讲都是软件；在底层来讲，都是代码通过函数指令操控数据返回结果的逻辑实现。

我们的工作不是画原型、包装概念，我们的职责是软件策划和管理，前者包含了商业模式和营销策略，后者包含了项目管理和运营机制。从这个层面讲，任何实体经济似乎都需要产品经理，而他们也确实都存在。

1、为什么关注软件开发模式？

（1）无论是IT公司，抑或互联网公司，PM首要职责是软件开发的策划与管理；

（2）对于小白而言，了解软件开发模式并准确把握其适用性，参与产品管理的整个过程将会更加流畅；

（3）我开始明白一个道理，工具只是锦上添花，用来争论和说服的信心和底气，始终来源于“专业”二字；

（4）天下武功，唯快不破；时间管理在项目管理阶段，更多的成本在于人员管理；当高手云集，灵活的方法，带来的是高效与品质。

2、几种常见的软件开发模式

（1）分类依据

从结果上来讲，首要诉求更侧重于效率还是品质，是分类的一大依据；

从过程本身看，项目目标拆分与执行的流程性角色权衡得来的结果。

（2）常见类别

A. 瀑布模型（Waterfall Model）

强调全局考量设计、研发、时间与资源的投入，同时系统开发应有完整的规划、流程与周期，且必须完整经历周期的每个开发阶段。这种模式可用确保系统品质，已经成为业界大多数软件开发的标准。

B. 快速应用程式开发（Rapid Application Development）

简称RAD，以最小幅度的规划迅速完成原型开发的模式，采用规划与开发交错同步进行，能够在没有大量预先规划的情况下，满足不断变更的需求，缺点就是开发人员可能被不断变更的需求折磨致死；所以，如果不是有个超级美好的idea+心理素质无敌的研发团队+封闭开发的节奏排期，还是不要尝试了。

C. 迭代式开发

迭代模型是统一软件过程（Rational Unified Process）推荐的周期模型，实质是迭代增量/迭代进化式开发，即每次只设计和实现这个产品的一部分，每一个阶段称为一个迭代，逐步完成整个项目。迭代式开发可以提供效率和成功率，降低风险的同时提高复用性，但是每一轮迭代都有可能通过不同层次的需求反馈来改变此前的设计与开发，因而不易明确目标，在缺乏优秀架构师的前提下，也不见得会降低过程成本。

D. 螺旋模型

这个模式也是有够奇葩，兼顾了快速应用程式开发的特征同时又匍匐在瀑布模型的裙脚下，当目标与需求均不太清晰的时候，项目只需要定义最重要的功能，然后不断轮回重复，直到定义清晰需求稳定，项目可以很快的逐渐展开。这个模型有个非常显著的特点：尽管需要在需求不明确的阶段进入开发，但会在每个迭代阶段构建原型，并进行风险评估，以便识别和消除风险，因而该模型更适合大型昂贵的系统级软件开发。

E. 敏捷开发（Agile Development）

相对于“非敏捷”的软件开发过程，这里不关心书面沟通，更注重成本最低最有效的信息流通和协作运转的效率。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。项目小组作为一个整体，按短迭代周期工作，每次迭代交付一些优先级成果，在检查调整后继续迭代；因此敏捷更适合50人一下的队伍。

---

【总结】

传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。

迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。

敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

3、敏捷开发流行的原因

（1）从业务视角看

A ——敏捷开发遵循迭代和增量的开发模式，以尽快实现和交付用户价值

反摩尔定律告诉我买，同样的产品所能获得的价值，随时间按一定斜率下降；错过一个时间窗口/产品推出的迟早，不仅影响获得回报的时间，还影响到产品价值本身。因此，时间和效率很重要，而敏捷的应对之道就是改变价值的交付模式——产品开发进程被划分成段迭代周期，每一个迭代的产出潜在可交付的产品增量，使得产品一部分价值得以实现。

B ——敏捷开发在增量交付过程中内建质量，以保证价值交付的可持续性

然而，增量交付并不是一劳永逸，可持续的迭代版本优化产品性能，以确保长期质量的价值交付，才能给组织带来长期效益。在敏捷中，主要体现为每一次的迭代和优化，都可以再周期内解决一批问题从而不让问题积累，同时还可以预防一些问题的发生。

---

（2）从开发模式和组织视角看

A ——实现问题域与解决方案域的映射

软件开发过程，实质是围绕问题展开解决方案的过程，即开发人员需要完成的是从问题域到解决方案域的映射过程。传统开发模式下，开发人员与用户之间的心智链接被割裂，缺乏与业务场景的直接沟通，只能围绕解决方案本身闭门造车，并不难回归到原始问题提供创新研发。然而，在敏捷模式中，问题始终是核心，场景化需求始终的开发的驱动力，即研发需要在问题域内对需求进行拆解和映射，围绕问题、场景需求展开研发过程，这样才能确保每一次迭代都可以满足一部分有效需求，也才能与增量交付价值相呼应。

B ——项目决策时间模型应是一个知识创建的过程

软件开发是一个知识创建于积累的过程，信息与决策的迭代需要以适应需求的方式传承并更新，方可将风险降到最低，确保每一次的增量交付价值和长期的交付质量；传统开发模式的决策是在项目早期形成的，在进入设计和开发后的任何变更都会带来意外成本；然而，在敏捷模式中，在适当时间做出适当决策，由风险来驱动探索性需求和测试，不断的推演和尝试，最终才能以最大化的积累决策所需的知识。

4、敏捷开发需要关注的3个概念

（1）时间盒（time-box）

可以通俗理解为1个迭代周期，一般为等长间距、具有稳定开发节奏、严格把控里程碑的迭代周期（通常为2-4周）；每个时间盒完成一部分功能，需要团队内外收集反馈，以便下个迭代周期的需求改进。

（2）潜在可交付的产品增量（potential shippable product incremental， PSPI）

关注PSPI，是敏捷开发执行效果的重要衡量指标，带来业务上调整的灵活性，并且全程均有内外反馈机制，可以充分暴露问题。理想情况下，如果每个迭代都达到可交付的质量标准，那么内建质量完美达成的基础上，不需要依赖最终的测试就可以确保产品质量和开发进度的监控。

（3）演进式开发过程（Evolutionary Software Development）

之所以称之为演进式开发，并不是因为时间上的堆积、需求的增量，而是因为全程都有反馈机制和灵活的调整策略，方便完善产品的功能定义、开发计划，确保每次交付的增量价值和长期的产品质量。

5、软件过程管理

（1）过程定义一个框架，软件过程定义软件开发的框架，包括技术方法和工具，这个过程构成了软件项目管理控制的基础。所以软件过程，是指软件整个生命周期，从需求、设计、开发、测试、发布到维护的一个过程模型；通过构建这样一个模型，建立一个环境便于过程各个环节的管理、交付质量的保证以及正确的反馈和变更。

（2）软件过程管理，需要明确以下实践行为，以确保高效、高质量的交付：

A 为团队成员定义角色身份和分配任务

B 定义会议类型

C 定义文档策略

D 定义QA指标

E 需求管理

F 版本控制

G 执行测试

H 代码管理工具

I 代码审查

J 经验教训文档化