一．Pair work的得与失
合作编程在以前的学习过程中也进行过，基本也就是各人负责一部分最后再将之拼凑起来，而这次作业要求的双人合作，要求的并不是这样，而是两人应该在一起进行工作，这样的要求理想情况下能在代码编写时提供更高的设计质量和代码质量，也能让结对人员之间做到相互学习，经验共享，促进交流，但是在实际情况中，因为结对对象并不是自选，我们之间的共同的空闲时间（因为课程，生活习惯等）不能得到保障，而在另一方面，合作对象之间的相互熟悉也花去了不少的相同的空闲时间，整体效率上也并不见得比分开工作效率高。
而在我理解起来，pair work要想要高效率的运作起来，结对对象的选择是一个很重要的部分，相比与还需要相互熟悉的之前较少交流的同学，或许室友什么的沟通起来更为方便，空闲时间也更为统一，而至于老师在课上所说的“pair work中两人相互督促”，不是在一个寝室的同学的督促无论是次数还是效果肯定是比不上同寝室的室友的。
疑问：pairwork中工作分量不平衡难道不会影响工作配合么，虽说我们pairwork只合作一次，但是在实际中未必不会出问题么？
二. 怎样通过一个有效的办法确定一个Bug的重要程度？我们知道，修改一个Bug时别的Bug处有可能会产生相应的改变，修改了某个Bug可能有的Bug的出错原因就发生了改变，也就是说，如果出现了一些Bug，应该先修改那些Bug会比较
有效率？怎样调整他们的优先级？
我自己尝试给出了问题1的答案：尽量缩短需求分析的时间，尽量完成基本核心功能，然后尽量拉长软件测试的战线，多测试，少加功能。这样可以赢得一些比较看重核心用处的高粘性用户，只要有一些忠诚的用户，做出来的产品就挺成功的。
三.PM不熟悉现阶段项目用到的技术，无法准确控制开发的时间和进度，Dev Leader懂技术懂代码但是队员的水平参差不齐，有些事情只有Leader能解决，这时候该怎么办？
我认为这时候解决问题的最好方法是Leader在对项目工程进行一些问题修复的时候让全队旁观，相当于每次的工作都是一次教学，毕竟大家的磨合才能使团队进步。如果水平的不足是既定的事实了，那么只好寻找方法去弥补。
四．测试与用户测试
书上也并为给出特殊的测试方法，不过其中一点——单元测试需要也必须由程序开发人员来进行。一方面是有些问题在部分代码完成时测试很容易发现，但是在整个工程完成之后却难以寻找，会极大的降低测试人员的工作效率与工作热情；另一方面则是态度上的问题——并不是说代码写好了，编译不出错就算工作完成了，自己的模块要能正确运行才算是完工。比起让他人来研究开发人员的代码，要适应不同的编程风格，弄清楚代码的意思所需要的时间暂且不谈，这也难免让开发人员产生“反正有人来测试”的不负责任的心理。
而用户测试则要求更高，各种神奇/奇葩的情况下都需要考虑到，而且最重要的一点是这些还未必会在用户需求中出现，“如果用户这样这样，会出现什么情况”，如果“用户输入那个，又会怎样”，这固然是要求开发人员在写代码的时候就将情况考虑周全，但另一方面来说人本身就难免出现纰漏，因此就有了后续测试的必要。而后续测试中要如何做到周全？就算是做到100%代码覆盖，也不能保证100%的正确性，所以才会有各种补丁的不断出现，所以才会有各种版本的更新…
总而言之，写代码和做其他事也没有什么区别，负责和担当总是需要的。
五．团队开发的若干
规则是死的，人是活的。当然MSF的那一套流程确实是成功经验的总结，但是在实际中能做到什么程度又是另一个未知数了。
在按标准流程走不下去的情况下，我们需要考虑哪些呢？团队项目的最困难的地方就是按时完成任务与队员间的沟通，其实那一套流程为的也就是保障这两点，也还好teamwork中各成员也都比较熟悉，估计相互督促沟通也不会太过于困难。
疑问：这只是针对我们学生的team而言，我们并不是专业开发团队，我们是否可只借鉴MSF中若干部分/按我们自己觉得方便的方式来开展我们的活动？