《构建之法：现代软件工程》阅读与提问

问题1：关于两人合作的一点疑问

• 在结对编程与两人合作一文中，邹欣老师提到了许多两个人之间磨合的策略与路线。
• 但有一点没有覆盖到，我也很疑惑，关于两个人合作的时候，我时常会有一种心态，就是感觉我应该提一种要求，但是也提多了也会感觉有一种“负罪感”，这也属于是磨合的过程吗。有什么办法克服这种心理。

问题2：对Scrum的灵活性的疑问

• 在Scrum/Sprint一文中，提到了Scrum在实践中可能会遇上的问题，可能会流于形式。但想Scrum如果严格执行为每天的会议，很容易会导致这个问题，因为有的时候，这几天的任务可能就是很重需求就是很模糊，大家可能根本也就干不出来什么东西。这个时候每天的会议不仅仅会流于形式，而且会破坏士气。
• 我认为Scrum Meeting的开展周期可以分阶段开展，而不是按照时间开展。

问题3：PM spec的具体实践看法

• 在邹欣老师的讲义设计阶段Spec中，提到了两个写spec的例子，一个是外星人系鞋带，一个是三峡的防水等级。两个例子都是非常具体的和有趣的。同时还提到了spec最大的两个问题是乏味和时间。但是文中并没有提到如何有效解决这两个问题。
• 我认为，spec作为对接用户与实现者之间需求的桥梁，实践中很重要的一点是让用户和实现者参与到spec的编写中来。在后续更新spec时，好好设计实现过程中的选择问题与创造性问题，让用户来回答。可以有效克服时效性问题。在编写spec时，让程序员参与审计与编写，同时适当让他们看到用户的原始需求的数据，把spec从指令变成一种讨论，可以有效克服乏味问题。同时避免了PM或者是spec编写者的个人主观意识对spec的影响。
• 这是我个人对于spec实践的一点看法，虽然会增加一些沟通成本，但是我认为这是值得的。

问题4：用户需求问卷设计的看法

• 我在其他活动中接触过社科类的同学怎么设计一个问卷，当时了解到的一个方法很有用处。
• 讲义中提到引导性倾向是一个很大的问题。问卷有一个很大的问题就是区分有效的问卷和无效的问卷，所以有的时候设计一些带有明显倾向的傻瓜题，可以有效的区分有效的问卷和无效的问卷。
• 问题定义不准确这也是文中提到的一个问题。但我认为这是一个需要折中的问题，太明确的是or不是问题，可能会导致用户的回答不准确，但加入一个没有关心过的选项，则能够有效的区分用户的需求。

问题5：关于典型用户和典型场景以及用户界面设计的一点想法

• 在用户界面设计一文中，提到了你姥姥的遥控器的例子，在前面也讲到过典型用户和典型场景的概念。
• 我认为实际应用中，典型用户可能可以分为几类，这个时候，我们或许需要给前端界面做一些可选项（而且是很容易找到的可选项）。就比如姥姥的遥控器可能需要一个大字体的显示，但是对于年轻人来说，功能丰富一点可能更好。这个时候，我们可以在界面上加一个“老年模式”和“年轻模式”的切换按钮，这样可以有效的解决典型用户的问题。
• 当然，遥控器这么做会很麻烦，但是在软件界面上，这是一个很好的解决方案。