在第七章设计阶段分析中作者提到对于需求分析不应该条条框框的完成需求内的要求，但是也不可以一味追求“最大的扩展性”。所以在需求分析和设计的时候我们应该保留什么样的弹性呢？
在七章开发阶段的日常管理中作者提到“要尽量减少非开发时间，不要动不动就开“全体会议”。团队成员们自我时间管理也很重要。”这个全体会议其实是很经典的问题，感觉其实当团队积极参与度不高的时候，全体会议就显得很没有效率，但是有时候又是必要的需要告知大家，或者希望大家参与讨论，应该怎么处理呢？
事后诸葛亮会议是对整个项目的回顾，总结经验教训，但是一些公司里人员流动大，去去留留一个项目能换几茬人，那么事后诸葛亮会议还有意义吗？会不会变成甩锅大会呢？
结对编程的好处书中已经详细描述了，那结对编程的不足之处呢？结对编程在现实生活中国内的公司似乎很少采用，是有什么局限吗？
典型用户是指，按不同维度来区分用户的过程中，在每个维度中能代表目标用户的那类群体。比如，按人数多少来划分的，能代表最多用户特征的群体；按盈利来划分，能代表带来最多盈利价值特征的群体。但是典型用户的定义和删除让我觉得非常奇怪，典型用户在何种情况下需要进行删除呢？
第三章提到过早扩大化/泛化会使整个软件变得四不像最后只能让后人来完善，怎样才能避免陷入这种误区，又应该在什么阶段对软件进行扩大化/泛化，使得程序更加完善？
第四章提到结对编程使用同一机器一同完成工作，那么应该如何根据各自的特长分配两个人的任务范围以取得更高的投入产出比？
第五章中提到为解决瀑布模型的问题提出了生鱼片模型和大瀑布带着小瀑布模型，分别有什么优缺点，这两种模型分别适应与哪种开发场景？
第六章中提到Scrum/Sprint能成功实施的关键在于Scrum Master，那么应该如何判断一个人能否胜任Scrum Master的工作？
第九章介绍的PM对团队起着重要作用，但应该如何处理好与团队成员的关系，了解成员的状态，合理分配工作来提高项目的完成效率何工作质量？
面对庞大而又零碎的需求，是如何从中化繁为简，捋顺思路，将各个需求串起来已进行功能的实现的呢？
那么作为团队中的一员，如何快速的找到自己的定位，完成自己可以胜任的任务呢，并且作为初入职场的新手程序员，如何让正确而又全面的向领导展现自己能力呢？
假如作为一个个人开发者，考虑的测试情况总是有限的，有什么办法可以帮助我们拓宽自己对软件可用性测试的思维呢？
有着各自的见解，无法迅速的达到统一，所以请问在这种情况下到底应该如何达成一样的意见，团队又应该如何去沟通交流思想呢？
我有个疑问，例如现在的某手机支付软件，为了利润投加了很多影响用户观感的广告，经常在使用的时候会无奈地误触到，作为用户我感觉软件的使用不够清爽，而反观某b视频软件，在广告以及一些不影响软件主要播放功能的小功能方面安排的很好，请问作为程序员在接受了用户这样的体验反馈后会做出如何的调整呢，如何在软件收益和软件使用体验之间做出均衡呢？
书中提到：
《构建之法》3.2 软件工程师的思维误区
“不分主次，想解决所有依赖问题：想马上动手解决所有主要问题和次要问题，而不是根据现有条件找到一个足够好的方案”