Ch00

406

如何理解大智的软件工程最核心的问题是要提炼出与需求相应的抽象？

作为一个学生，我能接手的项目一般为大作业或某些竞赛的项目，还有一些纯粹是为了自娱自乐(这个一般称不上项目)。由此可得我所要开发的软件的用户大多是比我们更专业、更有经验的老师，他们经常会习惯性的在不知不觉中将他们的需求进行了很好的抽象，而我们只需要实现就可以了。所以说，在校期间这种能力往往得不到很好的锻炼。希望老师能在用亲身经历帮助我理解这一核心问题的同时告诉我如何在大学期间提高这方面的能力。

如何理解阿超所说的软件开发的关键？

对于阿超所说的4点我也同意。前三点主要对应了软件过程中的软件描述，软件开发，软件的有效性验证和进化。最后一点针对的是团队内的成员该如何合作，与前三点在技术上对软件过程进行管理不同，这一点谈的是如何在人事上进行管理。在我仅有的几次团队项目的经验里，我感觉对于我们学生来说主要面临的困难还是在如何实现高效的代码和怎样激发士气上(曾记得，有一次我们团队因为遇到了技术瓶颈导致大家个个心情沮丧，如果这个项目不是作业的话恐怕就流产了)，而在需求分析和用什么技术实现上却没遇到什么问题(因为在校园里这些会有老师指定)。但是这也导致我们在实现的过程中因为没有认真做(或理解)老师给的需求分析而遇到很多问题(因为老师的需求分析已经给得很好了，所以大家不会在这上面再花多少时间，导致实现到一半时发现少了某些功能，或某些功能不符合需求等)。所以之后我意识到：需求分析不仅仅是做出来的一份文档，而是要开发人员都真正理解的开发指南，只有真正理解了它，才能做出有效的软件。

323

引子III : 有这样一句话：“我们村里能写VB的人不少，但是谁能做PM？”。

PM是否一定需要很强的Coding能力？PM的主要工作有哪些？

Ch01

415

我们平时做一些项目也需要用到这么大而全的工具么？虽然VSTS兼顾了MSF整个开发生命周期中各阶段和各方面的紧密联系，将工作项的管理同源码管理和构建管理整合起来，但是如果参与项目的人都各自为战，都只做自己的那部分事，最后才整合，那么这样一个从安装到使用都比较复杂的开发工具是否真的那么有用？

406

说实话，这一章我看得不是特别明白。主要是在自己按照书中所示创建团队项目时发现自己没有这个权限（后来知道Visual Studio Team Suit相当于一个client，貌似要用VSTF创建才行。当然，这只是问题之一），致使对TFS部分不是很明白。

在这里我还是想带着问题读下去（虽说章节末有一个详细图解的链接，但是在我访问它时被提示页面不存在），因为作为一个介绍软件工程的书记来说应该不会要求读者对该工具了解太深，并且随着内容的深入，我相信我会逐渐熟悉这一套工具的。

323

P5: 数据层提到了SQL Server 。

这是否意味着VSTS 将 SQL server作为一个必要的工具，如果没有SQL server 也就无法使用VSTS带给我们的便利。

P6  “VSTS =银弹？”

我觉的VSTS只是一种能够方便团队管理Coding的工具，而银弹是指一种能从本质上改变软件开发过程的方法。这两者应该是不能相提并论的。如果真的有了银弹之后，那么程序员是不是就像现在的建筑工人一样，整天埋头做Coding，从IT人才变成编程蓝领。到那个时候整个计算机行业的这么多人，应该如何解决他们的就业问题。再进一步想，世界以后的发展形势是否真的像意大利经济学家和社会学家维弗烈度•帕累托提出的"马特莱法则"一样，以后的世界只需要20%的人就能维持世界的正常运行。那剩下的80%该怎么办，世界是否会进入新的阶段——共产主义社会，还是变成20%的人对80%的人的残暴统治或歧视？

P21 图1-26

报表能够很好地显示事件的发展趋势，但是仅仅根据一个报表就能够准确的找出现象背后的根本原因，如果可以的话，那应该怎样做呢？

P23 “在征得阿超的同意后，就‘推迟’了缺陷24到里程碑2”

我们都知道软件的延期交付都是由于一个一个小问题没能够得到即时的解决而造成的。单单凭阿超一个人的同意，就可以推迟修改缺陷，那样会不会造成个人主观臆断呢？类似这样的决策应该怎样下才是最合理的？

P25  VSTS中的C++编译器对C++标准的支持更加严格

指的是哪些方面？

112

VSTS到底是个什么东西？软件开发的辅助工具？

使用VSTS开发到底带来了什么便利？我感觉各种版本代码的保存，管理，完全可以使用规范化的人为管理来进行，这样可以减少冗余，可以对旧版本代码的去留有的放矢。

Ch02

424

对于MSF的八条中的充分授权和信任我有一点问题，自己思考也没有得出结论，希望能得到解答，那就是充分授权和信任之前我觉得作为领导者应该要考虑合理授权这一问题（即使所谓的“史坦普定理”），但是在软件开发中，作为团队领导者应该怎样来判断自己的授权是否真确或者说是如何决策自己的授权，是仅仅从成员的技术层面上去考虑呢，还是有别的考虑？以及作为一个团队的开发成员，怎么样才能正确的自我定位，即使考虑自己有没有接受“充分授权和信任”这个“条件”的能力，希望能从一些切身经历得到回答。

415

移山公司是一个软件公司，开发应用软件、行业软件或者通用软件，开发的项目各种各样，如何能够保证公司所有参与开发的同事能够保持为同一个远景而工作，对于同一个项目，可能某些人觉得这个项目很有意义，觉得要将这个项目做到最好，但是老板却觉得没有必要将一个项目做到那么好，浪费人力物力。又或者某些人觉得这个项目丝毫激发不了他的兴趣，他只是将其当做一个简单的任务来完成，并没有全身心投入进去，不积极准备，这时候又该如何保证所有人为共同的远景而工作，或者这只是一部分认得远景，其他人只是帮忙完成而已？（2.2.2为共同的远景而工作）

每个人制定自己的时间表，从下而上的制定，如果某些人降低自己的工作效率而使得整体的时间下降怎么办？不压迫他们完成任务，但是如果完全由他们自己决定完成时间的话，没有一个时间限制的话那整体的效率不就低下了，到时候就算知道是谁拖延了时间，那还是要等待那个人完成，这不就又使得整体任务的完成时间往后拖延了么？（2.2.3充分授权和信任）

要做一个软件确实应该重视其商业价值，不然就没有开发的动力和必要。但是，一个好的软件创意如果没有资金的支持，如何实现其商业价值，如何保证自己的劳动。比如说自己有一个好的想法，但是自己没有足够的人力物力去实现或者自己实现了这个想法，但是却没有足够的资金去宣传，过一段时间，某些大型公司就会推出类似产品，那这种软件的实现还有什么意义，这种商业价值如何实现？

如何保证自己的商业价值？例如，为了保证自己的利益，防止用户过河拆桥，就在软件中设置后门或者安插某些恶意程序，一旦客户过河拆桥就利用之前做的准备工作来保护自己的利益?（2.2.5重视商业价值）

越是充分的信任，很多人就不自觉（见2.2.3），要什么激励机制，还是只能依靠团队成员的自觉？如果是商业软件，又该怎么办？

如果真的添加了某些强制措施的话，是不是又不符合为共同的远景工作，如何保证充分授权和信任的正确性同时又要保证大家都能够为共同的远景而工作?（2.7本章讨论）

412

书中提到组长（或其他层次的领导）不要把精力花到“询问”上，而应该将精力放在“帮助解决”上，这让我觉得作为一个领导者，他主要的精力会放在如何调配资源方面，那么他的领导力又将体现在哪方面呢？

各司其职，对项目共同负责。这样会产生一个问题，就是如果我要做一件事情，大家很多人持不同的意见，我又无法在短时间内说服他们，这种情况需要对此事负责的角色自己拿主意去做，那么做了决定之后又怎么说服其他人来共同负起这个决定的责任呢？难道要等到事情开始落实之后再接受吗？

开源/共享软件是怎么一回事？如果开源了，商业价值该怎么体现？现在是一个开源软件与非开源软件共存的时代，我们将如何看待这二者的关系？

406

保持敏捷，预期变化这一原则如何具体体现在项目开发的过程中？

这个问题的提出是因为就我的理解而言，若要保持开发的敏捷，最好是开发过程一气呵成（俗话说，一鼓作气，再而衰，三而竭嘛），然而要预期变化，就不得不在开发的过程中处处留有余地以便日后进行修改，且对变化的预期有可能会影响到为共同的远景而工作的具体实现（因为变化的存在很可能导致原目标不再适用，否则会使目标高度抽象而出现二义性）。所以我个人认为敏捷与变化并不是相互促进的关系，那么如何在二者之间进行权衡？如何将这一原则与实际行动相结合？这就是我的问题。

如何在规模较小的团队中推行MSF的这一套方法论？

MSF方法论需要程序管理者、开发者、测试者、发布管理者……如此多的角色对于一个小团队来说有些太多了。这使得在规模较小的团队中每一个成员都需要身兼数职，但是这样是否会分散该成员的注意力？又是否会有悖于各司其职，对项目共同负责的原则？如果这些都是兼容的，应该如何具体的实施？

MSF CMMI模式是否是一个普适（或比较普适）的模型？对CMMI先期投资是否会很大且在很久以后才能收到回报？

作为一个方法论的模型，我们可以认为它是道（即达到目的的一个方法，方法可能不止一个，例如“人道”。）。然而MSF CMMI除了能对软件过程进行指导外还有一个评价的功能，当一个模型具有评价功能时，它便上升为理（应该具有一定的普适性，比如“物理”。）所以说，对于一个软件过程没有达到CMMI规定的某些级别，我们只能说它不符合MSF CMMI这套模型，却不能肯定地说它一定是混乱的，不可取的。就我之前在网上查的资料显示，一个公司想获得CMMI更高级的验证往往要花两到三年的时间，由此可见实施CMMI的前期投绝对不会小。作为一个小公司或者说是一个小团队，要想在可接受的时间内看到回报是不是难了点？

作为学生，我应该重点关注MSF方法论的哪几部分，还是该方法论的所有内容都需要掌握？

这也是我比较关心的问题。因为作为学生的我来说除了要认识世界，更重要的是学习如何改造世界。MSF是一套系统的规模较大的方法论，我无法在短期内只通过书本掌握其精髓。那么应该将学习分为哪些阶段？每个阶段重点关注什么？

323

P30 “为共同的远景而工作” 这是否需要经常开会来强调呢？

 “保持敏捷，预期变化” 常言道：计划赶不上变化呀！

 “学习所有的经验” 有些东西没有亲身体会是不可能了解的呀，‘所有’是否说得太大了？

P35 这里讲了充分授权和信任的两大好处，那它的缺点呢？

 “领导在项目中的角色是‘支持成员完成任务’，而不是‘控制成员，迫使他们完成任务’”。

这是否是体现一个领导人的领导能力的体现呢？

P39 “衡量一个项目的成功，并不是最酷的技术，而是商业的成功”。

当代社会是以技术还是以商业作为推动力的呢？

P40-41 讲了关于开源的商业因素。

MySQL，Eclipse，这些著名的开源项目如果是以商业因素推动的，那么他们的商业因素有哪些呢？

如果说这些软件都是在Sun，IBM这样不为人知的秘密下开源的，那么推动Linux的开源的商业因素应该是没有的吧？

 “用户体验”。

如果是面向大众的项目，比如说windows 操作系统，在开发的过程中是怎样取得用户体验的反馈的呢？因为不同的人都是有不同的习惯的呀，Microsoft在开发windows这样的项目时是怎样满足用户的体验的呢？

P49 “各个阶段之间会有缓冲区”。

缓冲区虽然能够解决软件工程不能以理想化时间为标志的问题，但是如果两个功能，分别由A组和B组并行开发，并且只有在这两个功能都开发完了的时候才能进入下一阶段的开发。如果A组提前完成，而B组需要用缓冲区的这一段时间来完成，那么在这一段时间里，A组的成员应该干嘛？放假？加入B组？……放假公司肯定不干！加入B组那么等于重新调配工作，这只会延长其开发时间而已，没什么作用！那么……

P52 “会让软件开发人员不自觉地……一般用户往往不得其门而入”。

这应该是没有遵循模型和视图分离的原则把，界面开发人员开发出让用户熟悉的界面，而其后的功能实现由功能开发人员负责，只要接口实现好了，就不会造成这样的问题了。

320

P30：（最末段）第一个原则，用大白话来说，就是所有信息都保留，并公开，讨论要包括所有涉及的角色，决定要公开，并告知所有人。

问：在这里“所有信息都保留”“告知所有人”，一是把所有信息都保留了，看似没有遗漏，那在这大量的信息里有多少会被人看到呢，如果有选择的记录效率会不会更高呢；告知所有人，这样每个人都看的话，会不会浪费很大的工作时呢，为什么有这个必要？

P32：（最末段）这个目标不是空泛的，他应该对项目成员每天的工作都有指导作用。

问：我非常同意这个想法，但是实际操作的时候总是计划的时候总会出现这种情况：计划赶不上变化，怎么解决这种情况的发生？

P35：（阿超提出的第一个原则）平等协作----成员之间、团队之间是平等协作的关系。

问：MSF团队是这样的网状关系的话，那么在团队里有领导么，领导与成员是平等协作的关系么，领导应该发挥什么样的作用？

P41：（2.2.6）保持敏捷，预期变化

问：下面的文章描述的这个标题的必要性，但是如何预期变化，能否比个例子。

319

P51：2.5.2质量——防患于未然

如何防患于未然，有无具体的措施等？

119

第二章讲了MSF的八条基本原则，其中第七条是投资质量，其中讲到了非商业性软件的质量问题。那像我们的软件工程课程这样的课程作业是否也要把质量放在第一位呢？我们应该以怎样的心态面对这种非商业性质的软件开发呢？

MSF八条基本原则中强调了为共同的远景工作以及充分信任和授权，这样来看是不是相对熟悉的人在软件开发中会比较和谐顺利，新组成的团队要先进行培训呢？又如何解决熟人之间的问题呢？比方说拉不下来脸。又或者是不管人的问题，主要依靠这种MSF的方法和VSTS的方式严格进行控制会更好一些？

117

MSF的八条基本原则是所有遵循VSTS软件开发所必须要遵守的吗？比如说重视商业价值，投资质量等等，貌似在我们的大作业中我感觉不需要特别的关注吧。

MSF八条基本原则中强调了为共同的远景工作以及充分信任和授权，但是有时候同事是不能选择的，可是大家之间却又由于一些原因无法和睦相处的话，怎么样来保证互相之间的信任呢？这个我感觉属于人际关系方面的问题，对于大多数开发者（基本都是腼腆的书虫）来说，实属不易。

MFS的八条基本原则中的第六条将保持敏捷，预期变化。这个理解是很好理解，但是需要怎么做才能保持敏捷呢？我感觉对于开发者来说，能时刻感觉到用户的需求会发生变化不是一件容易的事。