问题一

多线程、多进程下的测试方法

• 不能回答的问题
• 在2.1.2中有提到，测试应当全面、准确、快速，随机测试效果并不是太好，因为如果随机测试的错误不可复现，那么测试本身于事无补。并且在100%覆盖率不等于100%正确性部分提到，多线程中的同步问题，和代码执行的时序、共享资源的锁定有关。
• 多线程本身运行时就类似于随机，即使正常的测试也会受到许多随机因素影响，导致出现错误很可能难以复刻。
• 那么多线程下与时序、锁相关的难以复刻的问题该如何使用测试来确保没有bug呢？或者说如何避免让正常的测试变得像随机数测试那样？

问题二

结对编程如何解决水平差距问题

• 不能回答的问题
• 在4.5.4中有提到，结对编程的双方应当只存在水平上的差距，没有级别上的差距，在分析、设计、编码上双方应当有平等的决策权利。
• 但实际上结对的双方往往水平差异会比较明显，很容易对架构设计等产生分歧，比如面向对象课设的架构上，每个人都会有自己的设计理念，优劣水平明显不同。那么当一方明显优秀于另一方的时候，为了优秀的代码质量，自然需要按优秀一方的设计进行，但最重要的是，若水平较欠缺的一方没有足够的能力来续写优秀一方的代码，这样按领航员与驾驶员的身份轮换下去，优秀的一方不仅需要续写自己的代码，还需要不停指导修改另一方的设计实现，其本质就是变成了一个人在主导全部主要流程，即领航员与驾驶员在实质上没有发生更换。或者说，这样不如明确的分工，一人负责产品，一人负责测试。
• 在这种一方很难赶上另一方的情况下，要如何进行有效的结对编程呢？是否应当继续进行结对编程呢？

问题三

如何保持敏捷编程的可扩展性

• 不能回答的问题
• 在6.1.1敏捷编程的开发原则中有提到，可用软件是衡量项目进展的主要指标，需要尽早并持续地交付有价值的软件以满足顾客需求，即以软件开发效率为优先。
• 一般来说，可扩展性需要提前认识到可能的需求，这些需求很可能不是当前顾客的需求，并且实现可扩展性需要大量的时间精力，就如同课上举出的飞机安全例子，这样看来，敏捷编程时应当牺牲掉对这些可能的情况的考虑，但是在多轮长期开发集成后，最初的代码将很难变动，此时可扩展性将会逐渐变差，导致进一步开发出现困难，甚至导致重构。
• 那么为了同时兼顾可扩展性与敏捷开发本身的特点，应当采取什么更加具体的措施呢？

问题四

如何应对竞争中实际存在的问题

• 不能回答的问题
• 8.4中提出了竞争性需求分析的框架，提出了NABCD模型与四象限图，其目的是为了在与其他公司的竞争中留下客户，让产品获得实质上的利益。
• 尽管其在理论上有完美的指导作用，但是实际上受开发人数的限制，“杀手功能”本身的开发就极有可能需要耗费过量的时间，即小团队起步时，会很难有能力去抓住杀手功能，甚至连所谓辅助需求都很可能是大公司已经解决的必要需求，因此会更加难以在竞争中产生优势。而大公司则可以加大对各种功能的开发投入，并且其根基往往决定了其已经实现的功能不在少数。
• 因此所谓的竞品分析需求图并非大小相同的三个圆圈相互交错，而应是大小不同的圆圈，并且我方优势取决于我方的基础、体量与可调动的人力物力资源情况，在这种实际上很严峻的情况下，又应当如何分配资源去实现功能呢？

问题五

ZBB相关问题

• 不能回答的问题
• 在15.1.5中提到的ZBB招数，在成功解决掉一版的全部bug之后，往往会遇到Bounce反弹，并且在多次这样的震荡之后才会逐渐趋近于0。
• 关于反弹发生的原因是什么？一般什么会引起这种现象？如果可以解释的话是否可以尽量避免反弹或者减小震荡的周期达到快速收敛呢？