提出问题
- 阅读《构建之法》，提出以下问题。
问题一：
P75：
结对编程让两个人所写的代码不断的处于“复审”的过程，程序员们能够不断地审核，提高设计和编码质量，可以及时发现并解决问题，避免把问题拖到后面的阶段去。
- 在此，我有些疑惑：结对编程这种模式是否不大适合我们这些在校学生，而更适合上班族？
- 就我们在校生而言，排除上课时间，课余时间相对零散，而大部分学生都有自己的安排。按照结对编程模式，结对的两人必须同步同台共舞，这就需要至少一人改变自己原有的计划。再者，每个人的编程能力不同，像之前团队作业中就有不少的人选择抱大腿，并美名其曰为结对。在此过程中，这部分人仍然得不到足够的锻炼。
而就上班一族而言，一周工作5天，每天固定时间上下班，且能坐在同一间办公室的程序员大体上都有相当的编程能力。这样就能很好的解决以上问题。
问题二：
P109：
冲刺到一半的时候，产品负责人突然发现要马上做重要的改动！或者某个大佬要看牧歌不在计划中的功能的演示，怎么办？这种情况非常考验Scrum Master。如果一个运动员在跑一百米冲刺，但是跑到一半的时候，领导突然想看一百一十米栏的比赛，前面马上回摆起栏架，大家要准备8步上栏！怎么办？
有正常头脑的运动员和教练员会说：去你的，要改主意，也要等到老子冲刺完了再说啊！- 我的疑惑是：产品的冲刺以一百米冲刺为比喻是否不够恰当？
- 个人认为：产品要做重要的改动和大佬要看功能演示，二者的优先级不同。如果只是不在计划中的功能演示，大可以冲他喊：“等老子冲刺完了再说！”但如果是重要的改动，我认为不得不让开发者中途停下。也就是说，重要改动的优先级高于功能演示。
- 若需要在做出重要改动时，Scrum Master 及时让开发者停下，等到整个冲刺过程结束后再提出。产品出现了一系列诟病，必须从头再一次准备冲刺，试想开发者会不会有“怎么不早说！”这样的抱怨？这岂不是浪费时间与精力，更打击了员工积极性。
以我之见，当必须要停下时，该停则停。Scrum Master应做的是为冲刺者争取足够的时间并为其加油打气。
问题三：
P238：
在设计软件界面时，我们的设计师经常会画新功能的UI设计图，来征求大家的意见。我注意到大部分设计都假设用户是第一次使用产品，所以没有任何积累的文件、照片、处理过的图像、曾经做过的选择等数据。我同意第一印象很重要，但是当用户已经是第N次使用你的产品时，你的UI能否为这些用户提供方便呢？
- 我存在的疑问是：当产品发布过一段时间，用户已经使用过N次，是否就意味着UI界面不能再做大的改动，而要习惯于之前的界面风格？
在阅读全书之后，我看到在第16章提到创新的概念。那么在UI设计上是否也可以大胆尝试创新呢？若我公司开发的产品一直沿用之前一贯的风格，而有后来者大胆尝试了新的界面风格。那么不谈功能设计，就用户体验的角度而言，会不会因为用户更适应新的产品而放弃现有的惯用产品？
问题四：
P326:
其实，大部分成功的创新者都不是先行者，例如搜索引擎，Google是很晚才进入这个领域的。又如Apple的音乐播放器iPod，发布于2001年10月23日，在它之前市面上已经有很多同类的产品了
- 那么，究竟创新的定义是什么，与山寨的关系是什么？
查阅了资料：
创新，拼音（Chuang Xin）缩写为CX，创新是以新思维、新发明和新描述为特征的一种概念化过程。其起源于拉丁语，有三层含义：第一，更新；第二，创造新的东西；第三，改变。
或许“模仿”一词比“山寨”来得好听。不论是Google还是Apple，都是在模仿现有产品的基础上提出新的思维、新的发明、新的描述。所以模仿是创新的必经之路。
问题五：
P328:
但是统计数据表明，70%的创新者说，他们最成功的创新，是在他们的拿手领域之外发现的。
- 所以说，要成为领域的专家，才能创新？
- 我觉得未必。现在市面上有诸如超级课程表、美团外卖、摩拜单车之类的APP，它们的开发者未必是学术界、餐饮业、交通行业的专家，但他们都实现了创新，发展至今已拥有了巨大的用户量。
所以我认为，不一定要成为领域的专家，只要有好的想法，人人都可以实现创新。