构建之法———其二

《构建之法》后面就介绍了软件工程的总体流程，需求分析、与客户交谈、团队分工以及PM、软件设计以及实现、测试软件以及提升体验，这些都是软件工程不可或缺的步骤。

　需求分析

　　软件是虚构的，需求是实体的，如果我们作为软件开发者，我们需要了解并进一步理解我们软件的用户所需求的东西，这个时候，经验与体验就是十分重要的。比如说，一个网站，应该是什么架构，什么商业模式，什么用户划分以及每个用户可以执行的功能，这些都要有所考量。书上总结了以下角度：对产品功能性的需求、对产品开发过程的需求、非功能性的需求、综合需求。对产品功能的需求有很多，就像课表，你可以分类显示课程、分时间显示课程、如何显示课程等；开发过程的需求，就是对开发流程进行限制，比如开发文档的需求，这一块给了我比较新奇的理解，因为我一直以为需求只是面向客户的；非功能性的，也就是对产品来说已经能用了，但需要有附加的性能、服务等需求；综合需求就比较广泛了，无论是对人员的需求还是综合系统的需求都涵盖。

　　需求包含前面聊过的软件需求、客户需求，如何分析一个需求还是问题。书中介绍了一种竞争性需求分析的框架——NABCD，N，公开明确的需求，A，下一步特别是独特的做法，B，好处，C，竞争性，D如何进行推广，通过这个框架能初步分析出需求。

　　团队分工

　　在团队里有很重要的一个角色是PM，这是个重要的角色，因为这是一种需要跨专业的职位，但一位专业的团队经理的功能也是显而易见的，无论是调节分工以解决交流成本问题，还是联系客户分析需求，同时也能做出重大决定。有一个优秀的领导人整个团队都会十分高效，这或许就是领头羊效应。这个领导人首先的富有领导才能，懂得问题的本质与解决，也能解决矛盾，另外对应专业也要有一定能力，但最重要的还是快速学习能力。碰到不会的需要指明方向只有PM能调动团队，不然七嘴八舌没个结果。

　　软件设计与实现

　　软件构造是个复杂的过程，但总体来说就是分析统一——实现设计——软件测试——编写文档，但这不是一条线的流程，因为很可能因测试不过关而重复无数次，这也是程序员害怕BUG的主要原因，为了尽快达成软件的实现，公司内部、团队内部都会建立每日目标，提交每日报告，以此督促员工的完成工作，只要不歇息，这一个过程将会是十分流畅的。但实际上，会有不少突发事件，包括训练新员工、项目完全重构、项目丢失等十分麻烦的事情，所以项目也不应该十分紧张，留有余地总会是好的。

　　我印象颇深的是作者在对风险管理水平的分级，一共四层，第一层一惊一乍的以为是大问题但却不去理会，没有预案；第二层准确来说是拖延，但确实采取行动去防止并解决问题，说是缓和但也只是让时间去解决问题，也没有可取之处；第三层就是有经验的应对，如何解决问题早已心有成竹，不会有大问题；第四次化危机为机遇，这是面对大危机也能自如应对的才能，项目被毙掉了或许就是这个项目的死亡，但提前布局针对前景进行开发工作，而且留有后路，这样就能在危机四伏软件工程中做一只不灭的小强。

转载于:https://www.cnblogs.com/limitCM/p/11006822.html

标签：需求,分析,其二,软件工程,构建,软件,团队,PM
来源： https://www.cnblogs.com/Rebz/p/15969468.html