个人作业-Week 1传送门
自问自答
Q1： “Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的‘经理’变成Scrum Master，大多行不通。”当一个团队在进行敏捷开发的时候，Scrum Master是唯一与外界沟通的人，那么原来的Project Manager应该做些什么呢？
Scrum Master的职责主要是把控和掌握整个Scrum节奏，保证项目顺利进行。而Project Manager的职责是正确地协调团队内部外部，调配各部门资源和时间，有效进行风险管理，保证一个项目顺利按计划完成。因此我认为Project Manager在Scrum中还是执行自己原来的职责，因为他的职责和Scrum Master并不冲突。
Q2：“微软产品团队三足鼎立的角色分配就是Promgram Manager、开发、测试。“那么，当一个团队的角色之间出现矛盾时，他们都是怎么交流以调和矛盾的呢，有没有什么经验性的方法？
关于这个问题，我们团队好像从没发生激烈的冲突。但矛盾是有的，比如两个人对于某一个功能或者说设计的意见不同，我们采用的是面对面交流讨论的方式，大家把自己的想法说出来，一般最后都能达成一致。
Q3：“另外，软件团队可以分析技术趋势以及产业的变化、社会发展的大趋势，推测用户会产生哪些新的需求。”这些“推测出的新的需求”在用户真正提出来之前是怎么处理的呢，是直接包含在设计中，还是等需要的时候再进行扩展？
根据我们团队的开发经验，在一开始设计的阶段我们就推测了很多用户的需求，但并不是一次性全包含在设计中。我认为我们是尽量根据用户需求将功能割裂开来，在一个冲刺阶段尽量设计实现和某一个用户需求相关功能，即我们的设计是等需要的时候再进行扩展的。
Q4：软件团队的“爵士乐模式”具有“不靠谱”的特点，“他们演奏时都没有谱子”。这里的“谱子”反映到软件团队上具体指什么，是指设计文档吗？如果是设计文档，为什么有些软件在没“谱子”的情况下还能做出一个优秀的软件？
我现在认为"谱子"指的不仅仅是设计文档，还有项目的管理方式以及参考的方法论等。对于设计文档，在结对编程或者敏捷开发流程中，由于团队的人员时刻处在交流之中，因此大家对项目各个部分都能达到较高的一致性，这时候设计文档对于开发一个优秀的软件就显得不是那么的重要，这一点在这学期的结对编程项目中我深刻的感受到了。另外关于团队项目管理方法，我认为软件开发团队的管理不应该生搬硬套某种方法，而需要根据实际情况进行调整，适合自己团队的管理方法才更有利于一个优秀软件的开发。
Q5：《构建之法》的概论中论述了计算机科学与软件工程的关系。作为一个计算机科学专业的学生，我时常会有一种硬件开发不如电子信息的同学，软件开发又没有软件工程的同学来的专业的感觉，并且我了解到的大多数优秀的计算机科学专业的毕业生最后都从事了软件开发相关的工作。那就找工作方面我们相比软件工程的同学是否不存在任何优势？
根据个人情况而定吧。我现在认为优势还是在个体之间比较才能体现。
Q6：伙伴测试(Buddy Test)能否用结对编程代替？因为我感觉结对编程也可以在签入代码前把重大问题解决。如果不能，是不是因为结对编程的成本比较高？
应该是不能的。区别在于伙伴测试时另一方对于新模块内部的认识以及投入的时间和结对编程时是很不一样的。这学期感受了结对编程以后，那几天可以说和结对的同伴除了上课休息几乎都是形影不离，大家都对整个项目有比较深刻的认识，并且都投入了大量的时间；而伙伴测试根据描述是“开发人员可以找一个测试人员作为伙伴，在签入新代码之前，开发人员做一个包含新模块的私人构建，测试人员在本地做必要的回归/功能/集成/探索测试”，如果改用结对编程，我觉得会给测试人员带来额外多的工作量进而大大降低整个项目的的进度，特别是当测试人员远少于开发人员时，比如我们自己的软工团队，只有一位测试人员，而开发人员有4位。
Q7：《构建之法》第17章强调了团队领导的重要性，团队领导的好坏会对整个团队造成较大的影响。作为一个学生，我也已经在一次次小组合作中体会到了这一点，一般大家都会更加倾向于听从团队里技术最好的同学，但有时候这样的效果并不是很好。因此我想问在一个团队中大家都不怎么熟悉的情况下，怎么样可以选出一个合适的团队领导？
我们自己的团队里的人实际上可以分成两拨，每一拨人内部很熟，但两拨人之间不怎么熟悉。当时我们选PM的时候是其中一拨人推荐了他们中间的一位，另一拨人同意。事实证明我们的选择没有错，我们的PM确实做的非常优秀（这里再为PM打个call）。我认为在我们这种团队的情况下，另一拨人需要给推荐出来的人更多的信任即可，也许就正好选对了。
做中学
需求：通过问卷调查来确定用户需求，用NABCD模型进行分析。
设计：尽量做一个好的设计，对项目后续的进展非常有用。
实现：注重代码规范，严格遵照设计文档，在遇到问题时及时与Scrum Master进行讨论。
测试：单元测试、回归测试以及压力测试的必要性。
发布：如何优雅而又不失礼貌的宣传自己的项目。
维护：收集用户反馈，以及用好issue的功能。