Yuxiang Zhu
A current master student in Nanjing University.
Email: zyx [at] smail.nju.edu.cn
作者是一位放荡不羁，与主流观点相悖的黑客，在书中提到的许多软件方面的观点都与软件工程传统思路不同，虽然我无法完全赞成作者的观点，但辩证地看待并分析《黑客与画家》一书使我受益匪浅。
首先作者对书呆子的评价使我耳目一新。在美式中学教育中，你越喜欢读书，越不受别人的欢迎。而作者认为书呆子都是高智商人群。当同龄人把精力都放在如何使自己更受欢迎时，他们不愿意将经历放在打扮自己，放在社交上，而是放在学习里。相比于学校里，书呆子会遭受到恶魔一样的待遇，在成人世界中，这种情况就好的多了。作者认为美国的公立学校教育体制出了问题，导致学生远离学习。
第三章仿佛是一个和软件完全无关的章节。作者认为从古至今，人们的思想都是随大流的，说出和社会违背的真话很有可能会遭受不公平的待遇。当大家不指出对方的话是错的，而是给对方的话贴标签如“修正主义”，“右倾主义”，那这时我们就应当警惕了。目前在美国，“政治正确”的风气登峰造极，和它相违背的都会遭受打压。作者希望读者能够不受这些社会流行舆论的禁锢，去思考那些惊世骇俗的思想观点。只要能看到别人看不到或者不敢看的东西，就会很有优势。虽然如此，作者建议对于这些“不能说的话”，想想就行，不要说出口，以免惹火上身。自由思考比畅所欲言更重要。作者还描写了很多应对的方式，都十分有益，如“将争论上升到抽象层次”，这里不再赘述。
作者认为小团体比大公司有着显而易见的好处。小团队每个人的贡献都是可测量的，因为每个人都能看到自己的努力对于团队的贡献。作者将大公司比作罗马战舰，虽然有上千名划船手共同划船，但船却滑不快，这是因为大家都看不到自己努力对于整体的改变，因此大家就没有努力的动力。就算自己努力了，看到不努力的别人也会想“凭什么我要为他的懈怠买单”。而小公司的个体却能受到有效的激励，因为他们能自发地为团体谋取利益。因此现在大公司内常常会建立小的团队，自己管理自己，自负盈亏，来开发软件。比如腾讯的光子实验室。这就是由于小团队中每个个体能受到更大的激励，能充分发挥自己的能力。
作者还对设计进行了探讨（不局限于软件方面）。作者认为好设计是：
我认为作者对设计的理解十分透彻，发人深省。
令人惊讶的是作者对Lisp，Perl等语言的推崇，而对java的不屑。作者认为java过于笨重，对程序员的限制太多。而Lisp十分轻便，容易开发，因此应当是创业公司首选。我认为作者说的不无道理。在当今互联网世界中，迅速开发即是王道，使用Lisp, python等语言有助于快速早期系统的开发。然而作者由于自身经验的局限（关注于创业公司而不是大型，长期的项目），没能够看到高复用性，代码可读性，健壮性对软件维护的重要性。在大型项目中，Lisp，python的代码可维护性不如java。由于java是静态类型语言，对程序员的容错率更高，因此维护起来更好。由于作者只短期内创立了成功项目Viaweb，没能长久地维持下去，因此没能看到多人维护代码时的困难。
虽然作者的部分观点在现在还是无法被世人（和我）完全地接受，但或许百年之后能证明作者是对的呢（比如java终究会落后于Lisp）。不过，作者的其他讨论让我如沐春风，至于其他更多引起争论的部分？让我们拭目以待。
本文作者是一名有着丰富领域经验的创业者，他先是自己创建了一个基于虚拟画像的互联网公司，然后将其以高价卖给了雅虎公司。随后作者在风险投资，扶持创业公司方面投入了大量精力。
本文第一篇章探讨了学习对衡量新创企业进展情况的重要性。作者竭力强调早期推出原型产品对于产品开发的重要性。开发者先推出仅有较少的必要功能的产品并面向早期顾客推出，这样企业就能够高效获得更精确的用户需求数据，并发现一些意料之外的客户行为。此外，能够在早期就避免一些可能的失败，并在顾客更喜欢的功能上下更多精力。
值得一提的是，甚至连政府部门这样的较为保守的组织结构也能使用精益创业的方式来构建原型。作者举例美国一个政府经济管理部门开发了一个原型来让政府机构在正式计划启动之前，先小规模地先行运作起来。整个实验成本很低，但学到了很多经验，比如政府能够了解公民认为自己遇到了哪些问题，是什么促使人们致电，还能够推断目标区域内真正致电的百分比。此外，还能从此产品中逐渐展开形成完善的解决方案。
关于客户需求调研，作者在下文还强调一定要“走出办公大楼”去调研客户需求。创业者不能仅凭借市场调研资料或者白板分析去分析用户需求，而应当与早期用户直接接触获得直观反馈。
本文定义了新创公司的商业模式循环：开发-认知-反馈循环。这个反馈循环是新创企业模式的核心内容，本书涉及的许多内容，都是尽可能将其循环总时间缩短。
作者在第六章“测试”章节中提到了最小化可行产品的概念，他能用最快的方式和最小的经历完成“开发-测量-认知”的反馈循环。最小化可行产品能够验证1.产品提供给顾客是有价值的2.公司拥有一个可行的增长引擎。最小化可行产品分为不同类型，如视频化最小化可行产品，贵宾式最小化可行产品等。最小化可行产品不用过于关注质量和设计，主要是验证商业假设是否可行，而且也能够避免产品转型时的成本。
作者举的他们自己创业中的一个例子让我深受启发。在作者创业早期，他们的虚拟人像系统遇到了技术难题，无法让人像在他们居住的虚拟环境中自由行动，避开途中障碍。他们索性直接推出了静止的人像，然后顾客点击需要到达的地方，人像就会瞬移过去。这样的功能十分简陋粗糙，却十分有效，受到了顾客的广泛欢迎。大家认为这样的功能节省了时间，十分奇幻。因此我们有时候并不知道顾客的真实需求是什么，我们想象中的顾客需求很可能和顾客需求有差异。因此开发最小化可行产品有助于我们理解真实的用户需求。
作者认为虚荣指标是应当严格防范的指标，我们应该避免诱惑，不使用这些指标。虚荣指标就是“总用户数量”，“总营业额增长”这些看起来很好看，实际上不能说明公司目前问题的指标。使用这些指标，创新核算无从谈起，真正的问题也可能被掩盖。相反的，作者鼓励使用三个“可”的指标：可执行（能够显示因果关系），可使用（产品报告应尽量简单可读；人们能方便地查看这些指标）和可审查（我们能亲自测试这些数据；生成报告的机制不太复杂）指标。
新创企业一般有三种增长引擎，管理者应当根据增长模式的不同选择不同的衡量指标和公司策略。三种增长引擎如下：
虽然一种企业可以使用多种增长引擎，但是作者认为这会造成很多混乱。因此作者建议新创企业每次关注一种增长引擎，只有彻底运用好一种引擎后，再转型到另一种引擎上。
此文作者结合了自己创业的经验来为新创企业提供经验，是一本不可多得的创业指南。
在传统的软件开发方法如Scrum，极限编程中，许多内容被事先规定好了，如团队成员的角色，迭代周期长度，大家该做什么不该做什么。而看板方法更像是一个“元流程”，可以根据团队现有情况调整的流程，团队可以很方便根据自身的现状进行改进，而不需要重量级的架构重组。
本书第一章，作者通过一个小故事幽默简明地介绍了如何在一个已有团队中引入看板方法帮助改进软件过程。故事中团队成员通过将工作项以可视化方式写在看板上的便利贴上，能够一目了然的查看到团队任务完成情况。此外，通过一个小游戏，团队成员体会到限制在制品对于提高交付速度的帮助。而为了应对紧急任务，团队成员还可以通过快速通道来绕过在制品数量的限制。最后，看板方法可以通过度量卡片流转情况来度量团队工作效率以帮助改进软件过程。
在书中第二章，作者将看板方法定义为一种在组织中创建渐进改革的方法，而看板是一种可视化流程管理系统。因此软件项目管理者可以放心地应用看板方法来渐进地，温和地改善流程管理。看板方法基于三个原则：可视化，限制在制品和管理流动。整个第二部分便是对三个原则的详细介绍：
除了这些基本的看板方法原则以外，作者在第三部分还介绍了一些高级看板方法。在第十二章，作者澄清了有关看板方法的几个陷阱，能够帮助读者在应用的时候不免不良后果。这些陷阱包括：
作者一共提到四种陷阱，这里不再赘述。我们必须意识到的是，看板方法只是一个工具，如何合理运用，裁剪这个工具需要团队成员共同的智慧。
这本书详尽地介绍了看板方法，使笔者回忆起本科在美团点评实习时对于看板方法的实践。当时在小组内，我们每早都会组织一个小型站会，围绕在看板前对工作项进行梳理，移动和讨论。 不得不说，将工作项清晰地可视化大大提升了站会效率，也使得每个人对于团队整体的工作进度十分明晰。而我们还将看板方法和Scrum迭代结合运用，获得了更好的效果。我建议任何有志于敏捷软件开发的软件工程学生都读一读这本好书。
人月神话与人件都是软件工程领域的入门必读书籍。前者注重于软件开发本身，注重于系统开发与设计中应当注意的事情；而后者则将软件工程中人的因素剥离开，单独来看人对软件工程的影响。在人件中，人被当作工程中的一个模块来管理。人件认为，软件工程中引起项目失败的因素更多地属于社会学范畴，而不是技术上的失败。
本书分为六个部分，第一部分探讨的是管理人力资源的问题。首先，作者指出软件项目失败率很大，而失败的原因常常不出在技术上，而出在“政治”上。事实上，作者认为，在软件领域，管理者应当更多的注重社会问题而不是技术问题。具体地说，作者提出了几个建议：鼓励大家犯错；给员工更多空间以鼓励大家创新；不逼迫员工加班，给员工更多空余时间使得他们在工作时间能更有效率工作；提高产品质量要求以提高生产效率（虽然听起来有点矛盾但的确是这样）。
作者不仅在第一章，而且在第三章提到：由于人力流失会带来很大的额外成本，如重新培训成本，项目延后成本，招聘成本等等，因此管理者应当尽力留住员工，为员工创造好的工作环境，让员工能满意自己的工作环境和工作状态，降低员工所受的过重压力。作者认为换人的成本大概等于雇佣这名员工两年总花销的20%，这是一笔可怕的支出！因此好好留住员工能极大地节省成本。为了留住员工，作者建议公司不要搬迁，定期培训员工等。
文章第二章对如何创造好的工作环境给出了建议。这其中大多是，非常具体实在的建议。比如作者给出了他对办公室整体布置的建议：要让大家能看到窗户。此外，公司应该为员工提供干净，干扰少，有隐私，高效率的空间，尽量减少开放式工位的设计。虽然这些建议如果真的实施起来，会增加一笔不小的成本，但这成本和提高的工作效率相比，简直是不足一提。作者十分注重工作时间的连续性，认为开发人员应当尽可能地不被打断（包括接听电话，被同事打断等），以获得更高的实际工作时间。此外，作者还提出了一些别的锦上添花的建议：比如让团队自行定制工作空间，增加公共空间的功能和面积等。
第三部分则谈到人力资源对于管理的重要性。作者对领导力的阐释发人深省：靠个人魅力来领导比靠职权来领导更有效，而个人魅力的塑造通过主动承担任务，胜任工作，为任务提前准备功课，让每个人创造更大的价值和保持幽默与善意。这样的领导能够更有效地激发组员的创新。
作者建议管理者仔细设计招聘以获得更适合项目的成员。管理者可以要求应聘者携带作品集以显示他们实际完成的工作，也可以组织一场试演来评估应试者的协调表达能力并使应聘者能更好地融入团队。
文章第四部分围绕如何打造一支团队来描写。构建一支有凝聚力的团队，能够充分发挥小组每一个人的才华。一旦团队产生了凝聚力，成功的概率大大增加。为了让有凝聚力的团队行程，作者认为管理者必须警惕以下一些管理上的错误：防御式管理（不信任你的成员）；官僚主义（比如过多的文案工作）；团队成员被物理上分割开来；碎片化的工作时间；牺牲产品质量；伪造过紧的截止日期；团队控制；用假模假样的励志标语或是励志纪念品来鼓励团队行程；加班。此外，作者特别提到要减少团队内部的竞争，使团队能行程一种互帮互助互相辅导的氛围，要让所有人都能够理解：个体的成功是完全建立在集体成功之上的。
第五部分作者建议管理者尝试构建良好的企业文化。让我印象深刻的是作者对会议风格的倡议。作者认为既不能开过于冗长的会议，也不能过于恐惧会议，害怕会议浪费时间。作者建议会议中应该减少参与人员笔记本电脑的使用，会使会议效率变得更加低下。会议应当使参与人员尽可能少（将参与者局限于利益相关的人）。作者建议我们提前确定好会议的开始和终止条件，以使效率提高。
当我在美团点评实习的时候，发现会议冗长的情况非常常见。一个会议经常可以开两小时，然后与会者通通打开笔记本电脑在各干各的事情。此外，许多会议在晚上七点后举行，实际上是变相强迫员工加班。这种会议方式事实上对建设团队非常不利，我们的小组成员能够通过会议获取的信息十分有限。
和会议一样，作者认为过多无意义的电子邮件也会造成团队成员时间碎片化，造成大家对邮件逐渐地不关注了，从而引起团队自毁。应该减少现有的大量无意义的抄送邮件，垃圾邮件和琐碎信息。
文章最后的第六部分则认为，工作应该是快乐的，只有当工作人员感受到工作的乐趣的时候，才能充分发挥他们的才能和效率。为了让大家保持工作的乐趣，作者建议引入一点混乱无秩序，使工作生活充满惊喜。比如开展试点项目，战争游戏，头脑风暴，素质拓展和培训，旅行等活动。此外，还可以让能力强的人担任组织里的“自由电子”，以充分发挥他们的才华。
总之，人件从各个不同的部分阐释了管理者能够做的改变。或许这些组织学上的，社会学上的创新反而能比技术上创新带来更多的进步。
从我大二的时候，软件工程的老师们就一致推荐人月神话作为软件工程专业的入门读物。在人月神话中，作者分条理阐述了许多从软件工程实践中总结出的经验，发人深省，为软件项目管理者提供了在对解决人与软件协调困难的一些解决方案。
首先，项目发生滞后的最主要原因是缺乏合理的时间进度。而缺乏合理的时间进度主要是由于：1.我们对项目进度的估算方法不太有效。2.我们的估算进度默认将进度与工作量相混淆，假设人和月可以互换。3.软件过程经理很少会持续地进行估算工作。4.对进度缺乏跟踪和监督。5.当意识到进度的偏离时，传统的反映是增加人力。此外，编程人员都是乐观主义者，直到项目出现严重偏离后，才会发现进度的滞后。作为一个学科，软件工程缺乏良好的数据估计方法。项目进度的落后通常是由于一天一天的落后逐渐积累起来的落后。这种小额，多次的落后比起重大灾难，更难以察觉，防范和弥补。因此，作者建议我们建立一个严格的进度表来控制项目进度，由里程碑和日期组成。其中里程碑是具体的，特定的，可度量的事件。此外，作者还建议我们制定pert图来跟踪项目进度，防止偏离里程碑，并能对项目进度偏离找到尽快的解决方案。甚至对于大型项目，作者还建议建立一个专门小组来维护里程碑报告。
我认为人月神话的一个核心观点是：在系统设计中，概念完整性是最重要的考量因素。即设计系统时为了保持系统各部分风格的一致性，宁可省略一些不符合整体规则的特性和改进。为了保证概念完整性，大型软件项目通常采用树状的设计结构，即由一个人或少数极有默契的设计人员来负责体系结构的设计。此外，体系结构设计与代码具体实现必须仔细地区别开来。在现代软件系统设计中，这一提倡被毫无疑问地实施了：大型项目中，由体系结构师来设计整体的结构，到各个子系统内，也使用由上往下的设计方式。由子系统结构设计师设计子系统的结构，再将实现任务分发给各实现单位。这么做也事实上加快了软件项目的进程，因为体系结构设计，实现和测试等工作可以并发地进行。由于成本的来源很大程度上是成员沟通和交流的成本，因此小型，精干的队伍是更好的，虽然对于大型系统中这显得太慢了。为了使整个系统能具有概念上的完整性，应该指定一个有经验的架构师，从上至下进行整体结构的设计。此外，作者还认为设计师不能画蛇添足，即牢记具体实现的开发人员也应当具有创造性和发明性，结构师不应该剥夺底层人员创造的乐趣。所以结构师只能建议实现方案，而不能支配。结构师应该对实现的建议保持低调，随时准备放弃自己对具体实现的建议。
此外我感到较为深刻的是，作者十分重视团队的交流，建议团队使用尽可能多的方式进行交流，建议团队通过正式的项目工作手册进行交流。在现代项目中，使用文档进行交流是非常重要的一个部分。作者还十分重视手册的设计，变更和维护。我认为这对现在项目十分有参考性。我们应当建立维护良好，实时变更的文档，来进行精确，无歧义的沟通。而且书面记录决策和分歧，有助于消除分歧，突出矛盾。此外项目经理还能够根据书面记录的文档来检验工作是否很好地完成。
没有银弹是作者最后提出的一个知名观点。作者认为软件系统具有其根本的，无法规避的内在特性：复杂性，一致性，可变性和不可变性。软件很可能是有史以来人类创造出来的最复杂的实体。作者将软件开发活动分为根本活动和次要活动。根本活动是打造构成软件实体的复杂结构，次要任务是使用编程语言表达这些实体的任务，在时间和空间限制内将它们映射成机器语言。除非次要任务的所有时间削减到0，否则生产效率不可能产生数量级的提高，这就是没有银弹。
总而言之，虽然本书著书至今已有四十多年，在互联网高速发展的今天，它倡导的软件工程方法依然有价值，我将本书推荐给每一名立志参加软件行业的学生。
软件管理沉思录是由一位经验丰富的管理者撰写的，结合实践和管理理论来为软件项目管理者提供指导的书籍。文章分为四个部分，分别是管理项目，管理团队，管理领导和管理自己。
第一部分作者探讨了对软件项目的管理。作者认为我们必须着眼于构建高质量的软件产品，并为高质量项目制定计划。如今软件的项目越来越大，对于软件质量的要求也越来越高。由于基于测试的质量保障方案已不适用，软件工程师必须尝试在软件开发过程中就减少缺陷的引入。作者认为我们必须对项目制定阶段计划和产品计划。产品计划包含产品的规格和性能指标，工作所需时间的估算，进度预测。作者认为良好的计划必须经过管理者的审查。此外计划应该满足以下几点要求：易于理解，清晰明白，详细具体，精确缜密和准确无误。作者认为可以不断动态地变更计划以符合不断变更的需求。此外，计划应当受到良好的维护。
第二部分是关于对团队的管理。和人件中作者一直强调的要打造具有凝聚力团队相似，此文中作者也高度看重高效团队对软件项目的重要性。作者认为好的团队需要大家有一致的目标，每位成员都扮演一个特定的角色，完成任务要求团队成员之间互相依赖。作者认为团队合作过程中应当警惕以下七个问题：缺乏有效的领导，缺乏妥协和合作，团队成员参与度不均等，拖延和缺乏信心，质量低劣，功能蔓延和无效的对等评估。作者认为可能造成团队失败的原因有以下几点：资源不足（如成员数量太少，培训不足等），缺乏清晰稳定的领导，目标不符合实际，士气不足。当一只团队彼此合拍时，他们之间产出的总和能超出每个个体产出的总和。高效团队必备如下四个条件：团队凝聚力，富有挑战性的目标，目标的追踪和反馈，共同的工作架构。在构建凝胶型团队时，交流十分重要，作者认为对于团队交流来说，一定要保持透明，倾听和协商。
作者认为领导力是决定团队成败的关键因素。首先，作者认为应当用承诺来激励团队成员。承诺的三要素是协商，约定和执行。有趣的是，团队集体承诺似乎比个人的单独承诺的激励作用更大。可信的团队承诺有四条要求：自愿，可见，可信和得到承认。此外，作者还建议建立短期的目标来制造紧迫感，能够避免进度大量落后。
文章第三部分探讨如何和自己的上级沟通。如果上级要求的完成时间不现实，应当勇于提出，并积极捍卫你的计划。在向上级做出任何承诺之前，都要有一个计划，然后根据计划来承诺。要让管理者和你商谈，如果自己的管理者不可理喻，就越过他，直接向更高级管理者反映问题。如果自己要提出过程改进，应当积极向管理者提出战略性理由，充分分析各项成本，理解当前业务环境，找出关注点并做一次合理性检查。同时，也可以为过程改进提出短期的战术性理由。
文章最后一部分则是建议读者管理好自己。一个精确控制的计划，和有质量控制的个人过程能明显帮助你提高。要做好自己的管理者，真正掌控自己的工作，并说服管理者同意由你管理自己。改变工作方式可以遵循如下的步骤：确定质量目标，衡量产品质量，理解过程，调整过程，应用调整的过程，衡量结果，把结果与目标进行比较，循环并且不断改进。作者认为应当对时间进行管理，包含以下步骤：把主要活动分类，记录每项主要活动所用时间，以标准方式记录时间，把时间数据放在一个便利的地方。
最后一章是对读者领导力的建议。你的所作所为都会影响团队，因此应当做好自己，为团队所有所做的事情负责，为团队树立良好的榜样。领导力是必须赢得的，是一个高度个人化的东西。最好努力成为一位变革型的领导，对工作充满激情。
在全书中，作者还穿插着对于PSP和TSP的宣扬。对软件过程的重视也是本书一大特点。
作为当下最流行的软件开发方式，敏捷软件开发在互联网蓬勃发展的时代，受到了大中小公司的广泛采用。不同于上世纪八九十年代的沉重，复杂的软件开发方式，敏捷软件开发在主张简单，拥抱变化的同时，没有放弃对质量的高要求，没有放弃对软件可持续开发的高支持度。
《Scrum指南》是由Scrum两位创始人共同开发和维护的为使用Scrum方法开发的团队提供指导的手册。在指南中明确提出Scrum是轻量级的，易于理解的，难以精通的开发框架。而《Scrum要素》一书更为详细地介绍了Scrum在实践中的有效应用方式。两本书都异曲同工地介绍了Scrum如何在实践中有效改善项目开发流程。
首先，敏捷价值观是敏捷软件开发的核心。敏捷价值观包括：
在《Scrum要素》中提到的敏捷原则则是对敏捷价值观的进一步深化和实际应用。作者列出了12条敏捷价值观。由于在软件工程学习的几年中，我们大多数实践的都是瀑布模型和迭代式模型开发，因此其中的几条与传统方法有别的方式令我略有感触：
其次，作者还提到了Scrum实践中的一些经验。作者认为：Scrum精髓在于小团队。小规模的团队具有很高的灵活性和适应性。敏捷宣言中提到“个体和互动高于流程和工具”，而小团队能够充分关注到每一个个体和提高互动效率。
此外，检验和适应也是敏捷开发当中的重要一环。敏捷开发中使用Sprint计划会议和Sprint评审会议来计划和评审产品增量和产品待办列表，使用每日站会来同步团队进度，使用Sprint回顾会议来尝试改进Scrum实践，使Scrum更适用于实际情况开发。和“敏捷”的特性相呼应，每日站会要求尽可能短暂，通常限定时间和地点。
有趣的是，与大多数其他领域的团队不同，Scrum团队以自组织的方式运作，即不由团队外的人来指导。Scrum团队包括产品负责人，Scrum master和团队成员。产品负责人负责管理产品待办列表。Scrum master负责根据Scrum指南来促进和支持团队内的Scrum实践。而团队成员共同组成了自组织，跨职能的开发团队。
共同作为敏捷软件开发中的流行的实践，Scrum和极限编程在互联网时代的地位正不断上升。只有良好地学习敏捷软件开发，并不断改进敏捷开发实践，我们才能在接近软件开发”银弹“的目标上更进一步。