软工网络15个人阅读作业2——提问题

提出问题

快速通读教材《构建之法》，并参照提问模板，提出5个问题。

问题一：

• p83有一段话：
  • 两人在一起合作，自然会出现不同意见，每个人都有自己的想法，在两个人平等合作的情况下，不存在领导与被领导的关系，如何让能说服对方？
• 虽然不存在领导与被领导的关系，但如果是在两方都不确定自己是最佳方案的情况下，是要说服对方还是要听取对方的的意见？还是要两个方案都尝试？哪种情况才能最便捷直接的解决问题？
• 我觉得合作的双方就算不存在领导与被领导的关系，也可能会有能力上的差异。就像这学期的结对编程一样，并非所有的同学编程能力都是一个水平，有好的就会有差的，也并非低能力一定要听取高能力，但是对于一个问题存有意见，还是应该提出来让大家一起思考一下，不然之后发展成大问题就更麻烦。

问题二：

• p118：
  • 软件团队开会，领导说：我们要采用敏捷的开发流程。很简单，就是木有计划，木有文档，马上写代码，随时发牢骚。
• 首先敏捷是什么？真的如文中所说没有计划文档的情况下直接开始打代码吗？
• 课本所提及的敏捷是一股思潮，或者说是一种价值观，涵盖了好几种软件开发的方法论；这些方法论又是建立在许多行之有效的最佳实践方法之上的。
• 敏捷的方法论有哪些？
• 爱抚弟弟（FDD）；史克朗姆（SCRUM）；极限编程（XP）；那这些方法论具体又是如何实施的呢？怎样的思想才能算是敏捷呢？

问题三：

-p129：

• MSF团队模型和MSF过程模型也是建立在“信息共享与沟通”原则上的。
• 什么是MSF团队模型？什么是MSF过程模型？

• 课本所提及的MSF（微软解决方案框架）有九个基本原则：推动信息共享与沟通；为共同的远景而工作；充分授权和信任；各司其职，对项目共同负责；交付增量的价值；保持敏捷，预期和适应变化；投资质量；学习所有经验；与顾客合作；那MSF团队模型，经过查找后如下图：
  

• 查阅资料后，得出了MSF团队模型的好处：各子团队的工作和职责相互依赖，这种相互的依赖性会鼓励子团队成员对由其他子团队工作做出评论和贡献，以确保该子团队成员所有的知识、能力、经验能够被应用到解决方案里。项目的成功，属于所有的子团队成员。他们共同分享一个成功的项目所带来的荣誉和回报。即使是一个不太成功的项目，也能做到全心投入并从中吸取教训，以完善他们的专长。

• MSF模型如下：
  

• MSF过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的，它把瀑布模型中基于里程碑的规划优势与螺旋模型中的增量迭代的长处结合了起来。

• MSF过程模型的基本元素是阶段和里程碑。

问题四：

• p214：
  • 规格说明书分以下两种：1.软件功能说明书，主要用来说明软件的外部功能和用户的交互情况。
    2.软件技术说明书，又叫设计文档，主要用来说明软件内部的设计规范。
• 功能说明书和技术说明书都是必要的吗？
• 软件也会有常用和不常用之分，如果一个不常用的软件，写一份功能说明书以及技术说明书需要耗费大量的时间，那这时写还是不写？当遇到这些情况时，怎样的决定才是正确合理的？
• 网上搜索后，得到了如下的解释：软件规格说明的使用者包括用户、设计人员、程序员、管理人员等, 涉及产品鉴定、质量保证、配置管理、软件维护、人员培训、市场分析、软件版权等诸多问题。可以把软件规格说明看成是一个具有概述、图示、例子等多视角的信息库。它既是用户和开发者的一份协议, 又是指导软一件开发、测试和维护的依据。
• 因此我觉得规格说明书是必要的，即便是不常用的软件，也总会有用到的时候，如果没有这些规格说明书，将会浪费大量使用者的时间去了解如何使用运行软件。

问题五：

• p230：
  • 当时他接到英国的求助电话。客户说，他们建立了一个模型，这个模型得到了客户、管理人员和开发者的共同认可。但问题是，有了这个模型，他们却不知道下一步该做什么！
• 这种情况在我们学习过程中可以说是很常见了，就比如说拿到一个编程题，自己心里也有了一些思路，但就是不知道从哪里下手。所以我们遇到这种情况的时候，该怎么做才能快速的进入状态？