读后感

Posted 2020-07-13

第八章

      看了第八章后，了解了第八章是需求分析的概论。

      正如书中所述，需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段包括：业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。

      很多人或机构都是软件的利益相关者，所以，在分析需求时要考虑这些利益相关者，比如说：用户，顾客，软件工程师等。

      获取用户需求——用户调查，是为了更清楚了解用户到底期望什么样的产品。因为，如果一味的凭借软件工程师自己的看法去设计软件，等到真正投入市场时才发现，这款软件不符合用户要求，那这样不是白白浪费了时间和金钱吗？为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求，确定用户所需软件产品的功能，不论我们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发者带来麻烦。所以，很有必要在获取用户需求时，做一份用户调查问卷，这样能更好的反映你所设计的这款软件的市场等情况。用户调查，在阅读这章书之前，我也曾经做过。现在看后觉得对那时的调查真的很有，老实说，有点后悔，当时没有阅读这章书。但是，现在看也不迟，因为以后可能还会用到。

      竞争性需求分析的框架，书上提到的是NABCD模型。N代表需求，A代表做法，B代表好处，C代表竞争，D代表推广。虽然只有五个字母，但是，在分析项目的时候很有用。毕竟，我们团队之前也用过NABCD模型分析我们的复利投资理财工具，所以，这其中的好处自然是了解的。

      功能的定位和优先级。绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。不管你选择怎样的优先级先后，都应该是可实现的、可测量的、文档化的，并且与你的客户指的“质量”一致。

      计划和估计。有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分不是写计划，困难的部分是作这个计划——思考，沟通，权衡，交流，提问并且倾听。你用来分析解决问题需要花费的时间，会减少项目以后会带给你的困难等。人们通常以日历时间作估计，但是我倾向于估计与任务相关联的工作计划（以人时为单位）的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求，会议，和所有其他会让时间消失的地方。

       分而治之。把大任务分解成多个小任务，帮助你更加精确的估计它们，并且保证更加精确、细密的状态跟踪。然后让不同的人负责，还有，PM要跟进这些小任务的进度，确保项目的高速以及正常进行。

      但我对第八章8.3节获取用户需求——用户调查存在着不解。令我很困惑的是：万一，我们调查的用户对我们要实现的软件完全不懂，然后还给了我们一大堆不符合市场需求的意见，然而我们并不知道，然后我们采取了这类用户的要求，最后做出来的产品完全没有市场价值可言。如果，这样的情况发生了，那我们应该怎么办呢？如果你在阅读本文，麻烦给点建议吧！愿闻其详，谢谢！

 

第九章

      看了第九章后，了解了第九章是项目经理的概论。

      正如书上所述，再加上鄙人之见，PM就是项目经理，是团队的领导, 带领、平衡、推动、激励、目标达成、交涉，平等工作之外管事不管人，负责除产品开发和测试之外的所有事情。

      书上还提到微软PM的来历。我觉得是一个很有意思的故事，我想贾伯大概是综合SP和MP提出PM这一头衔吧！

      PM做开发和测试之外的所有事情。书上列举了微软公司的几类PM，总的来说，PM就是要带领团队达成最重要的目标，并保持团队的平衡。还有值得注意的一点是PM管事不管人，毕竟，我们倡导平等工作。PM不做开发和测试之类的事，毕竟PM要负责太多的事，应该没什么时间参与开发。

      PM与风险管理。如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。PM要在整个项目的生命周期管理风险。风险有很多种，还有来源也不同。所以PM最好就对企业的文化有深刻的认识，有预备的方案最好。

      PM的能力要求和任务。书上列举了一些PM的能力，有，观察、理解、快速学习的能力；分析管理能力；一定的专业能力；自省的能力。还有，PM对团队的影响很大，所以，如果你是一个PM，那么最好争取得到你团队成员的支持吧！

      但我对第九章9.1节PM是啥存在着不解。在此之前，老师上课时有提到过，"团队的每个成员都要写代码，包括PM，还有PM管事管人"。但是，《构建之法》第九章，陈述的和老师说的完全不一样。令我很困惑的是：我到底要听从哪一种说法呀？如果你在阅读本文，麻烦给点建议吧！愿闻其详，谢谢！

 

第十章

      看了第十章后，了解了第十章是典型用户和场景的概论。

      典型用户和典型场景。大概就是非专业的程序员、专业的程序员、项目经理这三种人吧！典型用户很大的作用就是让程序员考虑问题时从用户的角度出发。定义完典型用户后，我们还要和典型用户的代表交流并理解他们。从典型用户到典型场景，要针对典型用户写典型场景，在从场景到任务，最后编写故事模板。

      用例，是需求分析工具。通过讲简单故事来传递信息。但讲故事较难，一般很难得心应手。所以，想掌握好，多努力吧！

      规格说明书。有软件功能说明书和软件技术说明书。功能说明书是从用户角度描述不涉及软件内部细节。而技术说明书是设计文档，描述了开发者怎样实现功能，这对于中途加入团队的成员很有用。

      功能驱动的设计。就是把用户的需求变成团队的开发工作，然后不断实现这些需求。它涉及到构造总体模型、构造功能列表、制定开发计划、功能设计阶段、实现具体功能这几个步骤。

      但我对第十章10.2节用例存在着不解。我之前也写过故事，而我写的故事是把任务拆分成故事，但是《构建之法》陈述的比较复杂，我也不是很理解。所以，令我很困惑的是：故事到底要写些什么呀？如果你在阅读本文，麻烦给点建议吧！愿闻其详，谢谢！