阅读《构建之法》

Q1:我看了这一段文字（软件系统是给用户使用的，用户的需求并不是要看这个机构的内部组织架构图，而是要解决用户的问题。 一个合适的团队结构，能更大地改进交流的效率，让团队更能把注意力集中在最主要的目标——解决用户需求上面。），有这个问题针对每个团队各自队员不同的脾性、能力，怎么在一开始选择一个“合适” 的团队模式。我查了资料，有这些说法（1.团员组成之际大家都应当有各自擅长的方面 2.多进行一些拓展活动让大家迅速的熟悉起来 3.根据大家的特点去挑选适合这个项目组的团队模式），根据我的实践，我得到这些经验（就以团队成员的身份而言，一个人要学会融入，不管一个人技术怎么过硬，都是需要团队的帮助的，但是还是很难避免团队之中有个别人员不太配合）。 但是我还是不太懂，我的困惑是（如若，既定了一个尽可能优的团队模式下，还是有个别团队成员不愿意配合，又该如何）。
Q2:我看了这一段文字（如果使用QWERTY键盘，那么只有10%的英语单词能在手指不离开键盘中列（Home Row，即ASDFG那一排）的情况下敲出来。但是如果使用Dvorak键盘布局，你可以在键盘中列打出60%的常用单词。但是，长期以来，人们已经习惯了QWERTY键盘，所谓先入为主），有这个问题如果我有一个更好的创新性想法，改变某一原有事物，使得它的效率大提高，但由于人们总是习惯于先入为主，我的创新性行为失去了意义，我还要继续吗？我查了资料，有这些说法（让别人清楚的看到创新想法与之前之间的区别，展示创新想法的优势，并勇敢尝试），根据我的实践，我得到这些经验（就我自己而言，在我用惯了一个软件之后，别人告诉我另一个软件其实更好用，我也依旧懒于尝试。）。 但是我还是不太懂，我的困惑是（如果我花费了大量心思完成了我的创新想法，但依旧没什么接受度，怎么办）。
Q3:我看了这一段文字（软件工程专家Paul Rook说，“我们其实并不是不会估计，我们真正不会的，是把估计后面藏着的种种假设全部列举出来”。），有这个问题我们在平时编程作业布置下来时，也常常错误估计了自己的预期完成时间，导致尝尝在ddl前疯狂挣扎，所以到底如何正确预估项目所需时间？。我查了资料，有这些说法（1.降低任务的分解粒度 2.使用任务列表，列表包括任何测试和集成工作），根据我的实践，我得到这些经验（就我目前依照PSP表格估计作业时间，但依旧和实践花费时间存在不小的差距）。
Q4:我看了这一段文字（每个人每天的高效率工作时段不超过3—4个小时。结对编程中驾驶员和领航员的角色要经常互换，避免长时间紧张工作而导致观察力和判断力下降。），有这个问题在结对编程中，两个经常交换角色不会导致打断思路，降低效率吗。我查了资料，有这些说法（一定时间周期地打乱配对，让参与项目的人员相互转换位置，容易让所有人都熟悉每个模块，这样对于公司也很有好处），根据我的实践，我得到这些经验（经常的角色交换虽然如何资料而言可以使大家对各模块更熟悉，但对我自己而言，角色的交换很多时候会把我既定的思路打乱，再次回到原来的位置时还要重新进入状态，效率降低了些许）。
Q5:我看了这一段文字（我们都用过各种电视/DVD播放器的遥控器，功能很强，按钮很多吧？你有没有注意到老人家使用遥控器时的困难？我们常说做产品要从用户的角度考虑问题，这需要有“同理心”。），有这个问题一个产品它的受众是许多的，每个人的适应度不同，虽有“同理心”，但大家感受不一，最后的设计到底该如何抉择。我查了资料，有这些说法（针对主要受众人群来抉择），根据我的实践，我得到这些经验（就如遥控器而言，功能展示在按钮上进行，于我来说感觉还是很方便，但我的家长就觉得如果简单些更好）。 但是我还是不太懂，我的困惑是（如果两个适应方向达到近1:1，如何抉择）