第一次阅读作业

项目	内容
这个作业属于哪个课程	软件工程（罗杰）
这个作业的要求在哪里	第一次阅读作业
我在这个课程的目标是	了解软件工程，并用实践来熟悉对软件开发的整个流程。
这个作业在哪个具体方面帮助我实现目标	阅读了《构建之法》，对软件工程有了基础的认识。

一.读完教材后的问题

1.第3章 软件工程师的成长——专与精的关系

书中在这一段将全栈工程师比喻成街卖艺的单人乐队，什么都会一些，但什么都不精。于是我对此产生了疑问，在我的想象中，全栈是很厉害的一个发展方向，一个人算法也能做，工程也能做，肯定是一个大牛。但在书中，对全栈的评价并不是那么高。于是我在网上查阅了之后，发现这就是一个深度和广度的讨论。一个人的精力是有限的，大多数人都只能在一个方面做到精通，或者在多个方面都做到了解。真正的样样精通是很理想化的一种追求，很多时候追求样样精通最后就成了样样不精通。因此我改变了我的想法，我希望我能成为T型人才，在学校时和工作早期，尽量去多了解各个领域的知识，然后再选择一个自己适合并擅长的领域垂直发展下去。

2.第6章 敏捷流程——6.2 敏捷流程的问题和解法

第二步：把一个任务从产品层级的描述逐步细化到技术实现层面，是很需要技术能力和交流能力的。

因此究竟要如何对一个任务进行细化呢，而且这个细化的工作是在产品最开始的时候进行的，因此如果细化工作时出现了对工作不正确的预估（很容易出现这种想当然的问题），在敏捷流程中又该如何解决呢？我在查阅了(博客)[http://blog.sina.com.cn/s/blog_72ae45e40101c2cm.html] 得到了下面的回答。

在经过目标故事评估之后，我们已经有了一份有优先级和工作量估算的目标故事清单和一个总体工作计划。一个总体计划通常要划分为若干个阶段性计划，通过对阶段性工作任务的安排和执行，来逐步完成总体工作计划。
每个阶段性工作以一个任务计划会议开始。
在任务计划会议上，首先通过目标故事清单的优先级和工作量估算，确定本阶段工作要实现的目标故事。
然后，根据本阶段要实现的目标故事，逐个对目标故事进行目标细化。在目标细化时，把目标故事分解成一般不超过8小时工作量的工作任务。把本阶段要实现的目标故事分解完后，就生成了本阶段工作的任务计划清单。
对本阶段要实现的目标故事进行细化，是由执行团队的承诺驱动的：按优先级，逐个目标故事细化到任务，直到填满这个阶段的团队工作总时数。通过这样的一个细化过程，执行团队就承诺了在这个阶段，按照团队工作总时数，能够完成的每一个细化了的任务。
目标细化的过程是一个形成执行团队共识，开展团队学习的过程。许多学习型组织的修炼方法都可以应用在目标细化的过程里。

从上面可以看到，这个敏捷流程的细化操作不一定要在任务的一开始就全部做完，可以先分几个阶段，然后每个阶段再分别细化流程。细化的过程要大家都参与进来，这样就会减少对细化目标的错误估计。

3.第6章 敏捷流程——6.3 敏捷的团队

1. 自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自主管理”不等于“没有管理”。
   . 自我组织：以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。

在这一段中，对敏捷的团队提出了要求。在这里我想到，在敏捷流程的要求下，是否各个项目中的分工可能就会变得模糊？组里的人要联合起来对项目负责，因此在敏捷开发这个流程中是否全栈工程师更加吃香？因此全栈是否在敏捷流程中是必要的？这些问题在网上没有找到较好的回答。

4.第16章 IT行业的创新——16.1.3 迷思之三：好的想法会赢

好的想法会赢学理工科的同学都比较理性，大多会认为，好的想法当然会赢啦。就像解数学题一样，好的解法当然会得高分啦。好主意一定会把不太好的主意都比下去。但是在现实中，好的主意不一定赢。例如，看看我们日常使用的电脑键盘，作者打赌99.9%的键盘都是这样的布局（QWERTY）
但是很多研究者认为下面的键盘布局（Dvorak）更有效率...
...
但是，长期以来，人们已经习惯了QWERTY键盘，所谓先入为主。

我认为Dvorak的键盘布局并不是一定是个好想法，因为，虽然设计出了更有效率的布局，但是它没有考虑到对于人们更换键盘并重新适应所带来的代价。而且这个效率提升也不是一个质变的提升，为了这种小的提升而去重新适应，换新的键盘，这个代价反而使得这个好想法变成了坏想法。

5.IT行业的创新——16.5 创新和作坊

作坊，英语叫Workshop，好多学术论文也发表在各种Workshop中，大家也觉得挺有面子的。美国好多家里的车库（Garage）、地下室都兼作主人的小作坊。在中国的上下文提到“作坊”，大家会想到什么？我想到：
自己手工劳动，做出产品。
人不多，师傅带徒弟，或家传手艺。
只做某种行业，不太改行，商业技巧不多。
不太做广告，主要靠口口相传，容易被技术进步淘汰。
和顾客很熟悉，可以赊账……
这些好像都不是缺点吧？为什么要着急走出去？我们一条一条地细说。
...
创新的出路到底在哪里？不能在各种峰会上发言的IT人士，不妨走进各自的小作坊。

对于这里的对小作坊有了好的评价，因此我想问一下，对于刚毕业的学生，到底是进入这样的小作坊去转研创业，还是进入大公司在公司的体制内提升自己呢？我自己暂时的想法是在职业的初期最好能进入一个小作坊，或者一个好的工作小组，努力提升自己。可能在这种环境，个人会有更大的提升。但我还是对这个问题不是很清晰，因为没有什么经验。

二.请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？

• 在1958年1月9日，美国的统计学家John W. Tukey在《具体数学教学》中使用了软件一词
• 在1969年前后,在阿波罗任务的任务过程中，Margaret Hamilton在美国宇航局工作时创造了“ 软件工程 ” 一词。

三.【附加题】：大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？

“埃尼阿克”诞生之初，由于它存在诸多缺陷，无法广泛应用。直到1951年，莫克利和埃克特在“埃尼阿克”基础上研制出了UNIVAC(通用自动计算机)，电子计算机才开始从实验室走向社会。不久，一件偶然事件的发生，又使其知名度迅速提高。
1952年，适逢美国大选。为了对选举资料进行处理，哥伦比亚广播公司租用了UNIVAC，用来预测大选结果。选举结束后仅仅45分钟，UNIVAC就计算出艾森豪威尔将以438票的绝对优势赢得胜利。但在选举前，几乎所有的专家和媒体都预测竞选双方势均力敌。所以对于计算机的预测结果，广播公司拒绝报道。工程师们只好重新计算，但该计算机仍坚持艾森豪威尔将大获全胜。当选举结果正式揭晓后，所有的人都惊呆了：艾森豪威尔实际得票为442票，UNIVAC的预测只有不到1%的误差率！从此，整个世界开始对电子计算机的功能有了新的认识，电子计算机的发展进入了一个新时代。

四.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？

软件	人数	优点	缺点
Github	31,000,000	错误跟踪，快速搜索，良好的社区，方便共享，良好的兼容性，支持Git，SVN，HG，TFS导入。	大小限制：文件大小不能超过100Mb，存储库可以托管信息1Gb。
Bitbucket	5,000,000	对于小团队免费，一个集成的查询管理系统，通过社交媒体和GitHub认证，集成Jira工具，导入现有Git项目，支持Git，CodePlex，Google Code，HG，SourceForge，SVN导入。	不开源，系统不稳定
Launchpad	3,965,288
SourceForge	3,700,000	代码非常多，从古到今，各类都有，版本控制多样选择	查看log很费事，很多没人管理的项目
GitLab	100,000	免费，GitLab在开源许可证下运行，错误跟踪和基于Web的代码编辑，与LDAP(轻量级目录访问协议)集成，支持Git导入	界面相对较慢，存储库常见的技术问题。
GNU Savennah	93,346
OSDN	54,826
Ourproject.org	6,353

参考资料：

• 版本管理软件用户数目