[I.1] 个人作业：阅读和提问

问题1：结对编程在实现代码复审上是否优于传统方法？

• 上下文：书中第86页4.5.3小节中提到，相比于传统复审，结对编程具有可以实现持久复审、复审人对程序理解更深、建立集体代码意识等优势。
• 问题描述：我认为书中仅提到了结对编程相比于传统复审方式存在的优势，而未提及可能的劣势。比如在只用一台设备的情况下，编程和复审的节奏可能难以协调，复审人也难以使用辅助工具，这些都会影响复审的质量和效率。此外，让代码的责任不属于某个人的处理方式也可能会使责任不明确，在某些情况下会出现踢皮球现象，未必优于传统方式。

问题2：敏捷开发中的任务分配是否会因时间估计的不准确性而过于频繁变动？

• 上下文：书中第115页6.1小节中提到，敏捷开发的第二步是将任务细化成以小时为单位后由成员认领。
• 问题描述：正如书中第八章所述，人们对任务耗时的预估往往会有较大的偏差，在团队经验较少时尤甚，敏捷开发中的任务分配以小时为精度，当须有先后顺序的任务被认领到不同成员时，是否会很容易因个别任务的实际完成时间与预估时间相差较大而导致整个计划推迟较长时间。

问题3：如何合理地确定典型用户？

• 上下文：书中第215页10.1.3小节提到了典型用户的定义，包括名字、年龄和收入、比例和重要性、使用这个软件的典型场景等信息。
• 问题描述：典型用户从之前的简单用户标签扩展到了现在的对具体人的描述，可由于对用户的描述维度增多，实际符合该描述的用户数也会较少，在细化描述的情况下应如何确定典型用户，并保证对这些人物画像的分析是能够真正把握用户需求的呢？

问题4：关于产品四象限分类中第四象限的处理方式

• 上下文：第八章和第370页16.3.6小节反复提到了产品的四象限，对于第四象限产品（即不是用户刚需，而是辅助功能，但我们有独特的方法做得更好）建议采取“维持”的办法。
• 问题描述：在许多情况下，产品的核心竞争力可能来自于实现了某些并非刚需但能极大提到用户满意度的功能，即第八章中提到的“惊喜功能”，对此的处理方式是否应当根据实际情况分为“差异化”和“维持”两种，又应当如何根据情况判断是否采用“差异化”的处理方式？

问题5：如何合理安排会议时长和频率？

• 上下文：第14章中提到，要尽量减少非开发时间，不要动不动就开“全体会议”。第六章提到敏捷开发中有每日立会环节，将每天的具体任务进度和问题都分享出来。
• 问题描述：在实际开会的过程中，由于各个成员负责的任务不同，其他成员汇报的大部分内容可能都与自己关系不大，如果会议过于频繁或漫长可能会影响整体工作进度，在这种情况下如何合理平衡工作时间与会议交流时间？