《构建之法》阅读提问

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	个人作业-阅读和提问
我在这个课程的目标是	了解并实现从”程序“到“软件”的转变
这个作业在哪个具体方面帮助我实现目标	阅读《构建之法》，学习软件开发的方法论

阅读提问

问题一：关于微软的MSF原则“充分的授权与信任”的疑问

《构建之法》P136 7.2.3

书中提到，MSF的开发原则第三条提出给予成员充分的授权与信任，MSF团队是充分给予团队成员权力的网状模型，而非层次结构，各个成员之间相对平等。我个人认为，授权如果不当，或者团队没有上下级的方式会导致某些不负责任或者无法全身心投入的成员有一些不负责任的行为，而此时如果没有一个主事的领导，可能会因为一个人的失责拖累团队，在这种情况是否MSF模型不太适用？或者说，应该是否应该在一个大家足够熟悉，保证团队人员质量的情况下才适合采用MSF模型。

问题二：A/B Test具体的作用是什么

《构建之法》P166 8.3.9

根据书上的内容得知A/B测试是使用两种不同的产品，根据用户的使用情况获取数据。但是进行A/B Test需要开发不同的UI，并且运维的时候应该也是两个不同的体系，而且会在5%-10%的用户上进行测试，所以运行成本并不低，但是在进行A/B测试时只能得到机械的访问时间、人数等数据，无法直接得到用户到底对哪个UI更满意，就像书中所说用户停留时间和用户是否喜欢这个UI也无法得知，所以我疑惑用一个成本不低的调研方式得出一个不确定的结果是否合适？或者是否应该在A/B Test的同时进行问卷调研，多种调研方式同时使用，或者告知用户你被选为进行测试的用户，希望用户给出调研的反馈。

问题三：UML是否真的有必要使用

《构建之法》P238 11.2.4

• UML是一个统一的模型表达方式，但是书中也提出了不同的技术大牛对其的质疑，例如Joshua Bloch说”能把设计画成图，让别人理解当然很好。但是说实话我真的记不起来那些模块应该是圆形，哪些是方形“，谷歌的研究院长也认为最好能用程序设计语言表达所有的事情。我在上OO课的时候也粗略的了解了UML图，但给我的感觉是UML图复杂，图形的属性众多，不好方便理解各种图形的意义，特别是一些接近的图形，如下图

  

  当时我在画UML图的时候也花了很多时间（相对于写程序和用文字表达)，所以比较疑惑的是是否在实际的生产中有必要使用UML图，或者UML图有什么明显的优点，值得花费一定的时间成本去使用它

问题四：关于有错不改是否是必要的

《构建之法》P305，13.5.1

本书在此提到一个Excel的bug——把1900年当作闰年。而此bug也是因为当时的头部软件Lotus 1-2-3首先出现了这个bug，为了支持此软件，Excel不得不将bug延续。

根据文章叙述，每个版本的Excel都有人报告这个bug，但是因为历史原因，这个bug始终得不到修复。我个人对于这种方式表示疑惑，因为闰年bug是一个比较明显的bug，并且从技术上修复起来并不困难，如果讲错就错是否会在之后造成更多的bug，如同由于Lotus 1-2-3出现了这个bug以至于Excel也保留了这个bug，而现在Excel作为电子表格的龙头产品，更多的软件为了兼容Excel也依旧延续这个bug，如此反反复复，问题始终得不到解决，可能造成更严重的后果。例如在作者博客提到出租车打表系统出错导致交通瘫痪损失30万元的新闻。所以我认为，与其将错就错，不如早日解决这个bug。

问题五：关于代码发布应该达成的要求

《构建之法》P329 第十五章

书中提到了在代码发布之后出现bug后的一系列措施，例如会诊、ZBB、砍掉功能等，但是我疑惑的点是什么样的代码可以发布。书中简要的介绍了Alpha、Beta等版本，其中Alpha是主要功能完整的试用版本，可能有一些小功能没有完成，Beta版本是稳定的功能完备的版本，给用户小范围使用。但是在实现的过程中，应该如何定义功能完备，是没有bug还是有一个基本功能的标准，只需要到达这个条件，软件可以有一定的bug？后文所提到的方法都是针对bug修复的，或者说是想让客户得到一定体验之后发现bug然后修复，所以发布的版本应该有一个明确的标准。