昨天在飞机上基本上算是第一遍读完了《软件研发之道》，这书第一版是1995年的，我买的是2006年再版，2011年人民邮电出版社出版，由于书太老买不到新的因此是在孔夫子买到的，可以点击这里在豆瓣上看这本书的详细信息。
看的时候跳过了不少内容，因为有很多以我目前水平看起来一知半解的东西，距离完全掌握这本书中的知识还差的比较远，但依然感觉书中有很多地方是值得我学习的，因此特意摘录这些内容出来。这些内容有一些是对我个人有益处的，有一些则是对团队有益处的。有一些是工作流程上应该优化的地方，有一些则是个人素质上应该强调的优点。
经验法则9：做权威，而非掌权者
分类：个人-个人素质
人们倾向于认为主管拥有父母式的权威，由于相信权威，团队成员认为权威人物的指挥就代表了最好的做法。明智的领导应把握一切机会，深入了解每一位团队成员的内心对于权威有什么期望。权威的目的是使每一个团队成员都成为他们各自领域的专家。记住，我们的目的是尽可能赋予每一名团队成员最大的权威，而不是将权力集中于一人。随着团队逐渐走向成熟，会有一名或数名真正的技术和产品专家涌现出来，同时提出适当的产品前景。主管必须完全信任这个前景，并将其有效传达给整个团队。
不说了，这方面差远了，慢慢努力吧。
经验法则11：与竞争对手不相上下？进行功能竞赛
分类：团队-工作流程
就软件本身而言，可以通过两种方式展开功能竞赛。一种传统的方式是针对竞争产品开发出大量功能，从而在产品功能上占据绝对的优势。这是一种蛮力式的竞争方法。在采用这种蛮力竞争方法时，最好竞争对手也采用同样的方法与你竞争，如果你碰巧知道竞争对手将采用并坚持这种蛮力竞争方法，并自信能够开发出在数量上远超竞争对手的产品功能，那么蛮力竞争方法就值得一试。但是这并不是开展功能竞赛的最佳方法，而且采用这种方法也不可能开发出优秀的软件。
开展功能竞赛的第二种方法，是投入大量资金和精力开发革命性的功能。至少开发出3个革命性的功能，即可确保你在这方面的优势。一旦你在这一点上取得突破，即使竞争对手之前暂时在功能数量上占优势，他也将被迫退回起点，重新与你竞争。但是你必须确保开发的功能确实能够实现革命性变化，如果不是这样，那它们只不过又是一轮功能战罢了。
之后安排迭代计划时的核心思想。
经验法则25：拒绝错误指示
分类：团队-个人素质
工作进度工作人员自己制定，这应该是一个基本原则。
这一条指的是要避免外行领导内行。书中说在业内有30%~40%的团队在功能在、资源和进度方面接受着非专业人士的指导，如果在这种情况下管理层的控制欲和支配欲很强，那么基本就要闹出灾难了。
在我们的团队中这种情况不是很严重，但开发人员依然给我一种“好吧你说啥就做啥最后的锅是策划的”这种感觉，因为在为每个版本制定计划的时候确实是由策划来发起的，程序偏向于配合，我不知道这是意味着策划已经牛逼到了安排的东西都非常合理的地步了，还是程序有些消极，我个人更倾向于相信是后者。
经验法则29：不要不懂装懂
分类：个人-个人素质
对于不懂的事物，不要不懂装懂，也不要认同其他人不懂装懂。几乎无一例外，最终困扰你的事物，往往是那些你之前不懂装懂的事物。人类的本性决定了人们讨厌自己不知道与切身利益密切相关的重要事务。由于在软件项目中存在大量未知事物，因此软件开发人员和项目经理往往会掩饰甚至是完全否认他们无知的程度，这已经成为一种普遍趋势。对于那些一贯列出自己当前不确定的事物的团队成员，应给予表扬和奖励。我建议项目经理应竭尽全力确保团队成员认识到他们的无知，而不是天真地隐瞒这种无知。向团队成员施压，直到他们意识到自己没有全面评估那些不确定的事物。我们没有时间兜圈子，必须直言不讳。
现在就让我们把它当做一个准则：如果对某事一无所知，最好的方法是坦白承认这个事实，即使你不确定何时能够交付产品。没有人会未卜先知，顶替掉你的位置。
软件开发项目的目标并不是提前指定准确的计划，而是在不确定的事物变成已知时，每天做出正确的决策。
这一条写给自己看，引以为戒。
经验法则31 小心“闭门造车型”开发人员
分类：团队-个人素质
这种闭门造车、长期不交付中间产品的天才型开发人员，并不适合那些以如期交付伟大软件为目标的开发团队。无论这样的开发人员多么有才华，都不能赋予他关键的开发任务，除非他理解并认同你打算运作的开发计划。这名聪颖的开发人员必须能够与团队成员协作，并定期交付中间产品供质保人员审查。一些天才开发人员无法忍受这种繁琐的管理，虽然这类有个性的开发人员可以在软件领域找到一席之地，但致力于如期交付伟大软件的开发团队绝不能选用这样的开发人员。
这会成为之后重要的评估标准之一。如果团队里有这种人会很糟糕，而当这种人并不那么天才的时候就更是雪上加霜了。
经验法则32 经常、定期构建软件产品
分类：团队-工作流程
- 频繁、公开的构建流程可以揭示真实的依赖关系，如果有任何关系没有处理好，产品就无法构建成功。
- 构建可以揭示无法预料的设计缺陷，如性能或规模问题，以进行及时的修复。
- 构建是使团队成员同时致力于相同目标的天然机制。
- 构建中出现的问题迫使团队面对他们想要忽略的问题。
- 这是了解项目真实进度的唯一方法。
由于每个版本的迭代周期只有一到两周，没有什么长期作业，并且还要提交中间版本，再加上研发团队一共也没多少人，因此我们在这方面做的还算凑合。但原文中给出的意见是定期构建产品，在最理想的情况下甚至是每天构建，频繁的构建版本确实压力非常大，但书中认为一旦能够克服，带来的好处是非常巨大的，就是上面提到的五点。
我们做得不够好，1是从来就没有做到过定期构建，而是慌慌张张的把功能搞定后立刻出版本，这种情况下构建出来的版本的质量可想而知；2是QA没有稳定的测试版本，开发人员一直在从trunk上把通过自测的代码merge到最终提交的正式branch上，因此QA也不知道自己测过的问题再update之后是否还需要重新测试。这非常浪费时间。
如何能够提高这方面的能力，还需要进一步团队内讨论。
经验法则36 完成每个里程碑后进行事后总结，但不要指责
分类：团队-工作流程
完成一个里程碑后，应立刻进行一次事后总结，有一些百问不厌的问题，例如：“当我们认为一切尽在掌握时，究竟为什么还是整整逾期了一倍时间？”好的事后总结并不是严厉的指责，也不需要花费多贵的成本。突出强调做得好的地方是特别有用的。里程碑的事后总结是一种很好的机制，通过它可以形成加固的、制度化的学习过程。
在延误里程碑后，不论以何种方式惩罚人，都会适得其反。如果你促成团队对许多里程碑都做了足够的反省，而且团队成员从他们自己的错误中总结并吸取了经验教训，那么团队最后就会走向成熟，按时达到每个里程碑。
没啥可说的，照做吧！
经验法则41 寻找自然出现的里程碑
- 设计趋于稳定
- 可交付成果变得“干脆”
- 团队认识到真正需要完成的工作量，这通常会发生很多次，而且往往是在进度延迟之后才认识到的。
- 设计被删减，或是资源增加，或是进度落后——往往这三者会一起发生。
- 开发活动停止。
- 产品进入结束调试/定型阶段。
这六个“自然的”里程碑不仅在整个产品开发周期中出现，也会在每个里程碑中出现。项目经理应该重视和长期培养这种行为模式。
虽说作者表示这些阶段是必然会出现的，但我反思我们的做法，往往并没有第4阶段，而是采取死亡行军的方式拼死修正功能。我们的团队由于种种原因，天然有着往里加入过多功能的倾向。我们的程序团队个人能力比较出色因此第3步已经不怎么出现了，但4的问题还有不少。1和2阶段往往也在和3一起出现，这两个阶段应该尽快提前。
这6个过程中具体都要干些什么，我现在还不太清楚，之后需要带着这个意识在研发过程中不断关注，同时之后找机会重读这本书。希望积累更多经验之后重读此书能有醍醐灌顶的感觉。
经验法则42 虽落后，别趴下
分类：团队-个人素质
进度落后没什么，它并不是世界末日。就像头疼脑热一样，它会令人感觉难受，但也正是身体正在进行自我治疗的一个信号。我们不妨从另外一个角度来看落后。进度落后就像是从软件梦境中惊醒一样，你们开始认识到现实。你可以把这种不断的觉醒看做成长的过程。在任何项目中，这种周期性的觉醒通常伴随着进度落后，但很危险，但确实可能发生。以下是在发生进度落后时一些大有帮助的做法。
- 记住不能用道德的层面来度量落后。应该卸去所有与进度落后有关的道德上的包袱，并且坚决要求你的团队也采取这种态度。讨论进度落后时东拉西扯企图隐瞒漏洞而突出优点，逃避谴责而追求表扬，这种道德上的倾向是极度危险的，因此必须尽一切可能抑制它。
- 不要隐瞒事实。
- 利用落后来激发人们的有效行为。由于意识到落后是一种觉醒，因此团队成员会获得新的领悟、信息、观点和先前未想到的可能性。一定要集中你的所有注意力对落后做出最有效的反应。落后就是显示团队灵活性的时候，要充分利用它。
1和2我们都做得很不错，我们直男癌风格的办公环境给了我们这方面的优势。但是3做得很差，因为我们已经习惯了每个版本都各种程度上延误，而失去了这种警醒，这是很可怕的事情，因为如果团队对此习以为常，团队就失去了成长的机会，而从个人角度上长期的加班浪费精力从而长远的削弱个人能力。
第一次读书下来觉得值得摘录的就是以上的内容了，我自己回顾了一下，发现大部分都是集中在沟通、团队成长方面的内容，说明我个人比较关心这方面的问题，所以之后会继续看怎么解决这些方面的问题，同时要注意观察其他方面是无懈可击了还是我没看到？我倾向于后者。
ManiaHero 