个人作业-Week 1
1）快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上。
Q1：“Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的‘经理’变成Scrum Master，大多行不通。”当一个团队在进行敏捷开发的时候，Scrum Master是唯一与外界沟通的人，那么原来的Project Manager应该做些什么呢？
Q2：“微软产品团队三足鼎立的角色分配就是Promgram Manager、开发、测试。“那么，当一个团队的角色之间出现矛盾时，他们都是怎么交流以调和矛盾的呢，有没有什么经验性的方法？
Q3：“另外，软件团队可以分析技术趋势以及产业的变化、社会发展的大趋势，推测用户会产生哪些新的需求。”这些“推测出的新的需求”在用户真正提出来之前是怎么处理的呢，是直接包含在设计中，还是等需要的时候再进行扩展？
Q4：软件团队的“爵士乐模式”具有“不靠谱”的特点，“他们演奏时都没有谱子”。这里的“谱子”反映到软件团队上具体指什么，是指设计文档吗？如果是设计文档，为什么有些软件在没“谱子”的情况下还能做出一个优秀的软件？
Q5：《构建之法》的概论中论述了计算机科学与软件工程的关系。作为一个计算机科学专业的学生，我时常会有一种硬件开发不如电子信息的同学，软件开发又没有软件工程的同学来的专业的感觉，并且我了解到的大多数优秀的计算机科学专业的毕业生最后都从事了软件开发相关的工作。那就找工作方面我们相比软件工程的同学是否不存在任何优势？
Q6：伙伴测试(Buddy Test)能否用结对编程代替？因为我感觉结对编程也可以在签入代码前把重大问题解决。如果不能，是不是因为结对编程的成本比较高？
Q7：《构建之法》第17章强调了团队领导的重要性，团队领导的好坏会对整个团队造成较大的影响。作为一个学生，我也已经在一次次小组合作中体会到了这一点，一般大家都会更加倾向于听从团队里技术最好的同学，但有时候这样的效果并不是很好。因此我想问在一个团队中大家都不怎么熟悉的情况下，怎么样可以选出一个合适的团队领导？
2）请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
“软件”：
1.1953年8月；
2.在兰德公司的研究备忘录中；
3.Richard R. Carhart；
“软件工程”：
1.1968年；
2.在“阿波罗”太空计划期间，在NASA；
3.Margaret Hamilton；
【附加题】：大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？（不定期更新）
1.女性在软件工程中扮演的角色：在1970年以前，男人们会在更有声望、更有报酬的硬件工程中扮演角色，他们常常把软件的写作授权给女性，而诸如格蕾丝·霍珀(Grace Hopper)或玛格丽特·汉密尔顿(Margaret Hamilton)这样的传奇人物也填补了许多计算机编程工作。
2.软件工程专业正式开始的标志：1968年和1969年，北约(NATO)科学委员会(NATO Science Committee)赞助了两场关于软件工程的会议(Garmisch,Germany - see conference report)，这给了该领域最初的推动力。许多人认为这些会议标志着软件工程专业的正式开始。
3.在软件危机中，一些软件项目甚至造成了生命的损失（当然这个并不有趣）：
It was involved in at least six accidents between 1985 and 1987, in which patients were given massive overdoses of radiation.[1]:425 Because of concurrent programming errors, it sometimes gave its patients radiation doses that were hundreds of times greater than normal, resulting in death or serious injury.[2] These accidents highlighted the dangers of software control of safety-critical systems, and they have become a standard case study in health informatics and software engineering. Additionally the overconfidence of the engineers[1]:428 and lack of proper due diligence to resolve reported software bugs, is highlighted as an extreme case where the engineer's overconfidence in their initial work and failure to believe the end users' claims caused drastic repercussions. --引用自《Therac-25 - Wikipedia》
大意：在1985年到1987年间，至少有六起事故发生，其中有大量的辐射剂量。由于并发编程错误，有时它给病人的辐射剂量是正常的数百倍，导致死亡或严重伤害。这些事故凸显了安全关键系统软件控制的危险性，已成为卫生信息学和软件工程的标准案例研究。此外，工程师们的过分自信和缺乏适当的尽职调查来解决报告的软件缺陷，被强调为一个极端的例子，工程师对他们最初的工作过于自信，并没有相信最终用户的索赔引起了激烈的反响。
3）上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
Microsoft TFS:
优点：1.任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用；2.集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM；3.能与 VS 无缝接合；
缺点：1.用浏览器访问相当慢；2.XP 系统无法访问。
Git：
优点：1.版本库本地化，支持离线提交，相对独立不影响协同开发；2.更少的“仓库污染”；3.把内容按元数据方式存储，完整克隆版本库；4.支持快速切换分支方便合并，比较合并性能；5.分布式版本库，无单点故障，内容完整性好；
缺点：1.不支持中文；2.图形界面支持差；3.使用难度大。不易推广；
Mercurial：
优点：1.跨平台；2.命令行简单易上手；3.可扩展性，易于根据用户需求自行定义、扩展；
缺点：1.分支管理不灵活；2.社区支持较差；
GitHub：
优点：1.功能设计简洁，可用性好；2.Git存储库服务，基于web，允许使用Git的源代码管理功能，或者其特性；
缺点：1.国内访问速度太慢；2.不能很好的解决GB2312/GBK，对中文不够友好；3.github:fi贵；
BitBucket：
优点：1.简单易学；2.支持中文；3.私人项目免费；
缺点：1.不开源；
Trac：
优点：1.灵活性高;
缺点：1.功能一般；
Bugzilla：
优点：1.支持中文；2.有强大的定制功能；3.免费；
缺点：1.安装繁琐；
Rational（查到的资料较少）：
优点：1.跨平台；
缺点：1.软件体积大；
Apple XCode：
优点：1.编译速度快；2.易于开发和维护；
缺点：1.插件不能随版本及时更新；
