具体描述
Jim McCarlthy等的《软件研发之道 微软开发团队的经验法则》叙述
了微软Visual C++开发团队的故事，通过作者的总结和归纳告诉读者如何
构建一个优秀的软件开发团队，如何在一段时间内成功地交付一个软件。
作为升级版，作者将言简意赅的法则扩展到57条，包括了软件研发及营销
的全部内容，相信每一位项目经理都会对此书爱不释手。
《软件研发之道 微软开发团队的经验法则》适合软件设计者、开发人
员、营销人员及技术主管等阅读。
作者简介
Jim McCarthy 具有二十多年从事软件开发工作的经验。先后供职于AT&T 贝尔实验室及白水公司，现任微软Visual C++事业部总监。时常在世界各地开研讨会，发表演讲。
Michele McCarthy 微软供应链计划经理，拥有12年高科技领域工作经验。
目录信息
简介 2
有关软件的思考 3
项目的阶段 6
开局阶段 7
组织 7
质保人员是“少数民族”吗 8
到底谁负责产品设计 8
经验法则1 建立共同前景 9
经验法则2 使大家主动投入 18
经验法则3 制定多版本的技术计划 20
经验法则4 不要认为别人是笨蛋 25
死亡行军 27
经验法则5 搜集情报 30
经验法则6 注意团队成员组成的比例 32
经验法则7 组建功能小组 33
经验法则8 项目经理的重要性 41
团队精神 42
经验法则9 做权威，而非掌权者 44
竞争 47
人类学分析 47
软件竞争 49
经验法则10 缺乏竞争对手？未必是好事 50
经验法则11 与竞争对手不相上下？进行功能竞赛 52
经验法则12 落后于竞争对手？更频繁地推出新版本 52
经验法则13 领先于竞争对手？绝不放松 55
经验法则14 紧跟潮流 55
客户 57
简单的购买模型 59
经验法则15 让客户惊喜 60
经验法则16 找到靶心 62
经验法则17 与客户建立良好的关系，而不只是生意往来 63
经验法则18 加快产品周期 65
设计 67
经验法则19 追求伟大 67
经验法则20 确定主题 68
经验法则21 将依赖减至最少 70
经验法则22 平息客户的抱怨 71
经验法则23 软件的可移植性 71
经验法则24 在设计阶段考虑时间因素 71
开发 73
经验法则25 拒绝错误指示 75
经验法则26 以游戏的心情开发软件 76
中期阶段 79
经验法则27 像医生一样 79
经验法则28 记住软件开发金三角：功能、资源和时间 82
经验法则29 不要不懂装懂 84
经验法则30 提交中间产品 87
经验法则31 小心“闭门造车型”开发人员 91
经验法则32 经常、定期构建软件产品 94
经验法则33 始终完全了解产品的状态 97
掌握进度 98
经验法则34 利用零缺陷里程碑 99
经验法则35 一个也不能少，才算真的到达零缺陷里程碑 100
经验法则36 完成每个里程碑后进行事后总结，但不要指责 101
经验法则37 把握里程碑的字面意义与精神 101
经验法则38 掌握什么是“正常的” 102
经验法则39 里程碑的合理数目 107
经验法则40 每一个小的里程碑都有专属的意义（故事） 107
经验法则41 寻找自然出现的里程碑 109
经验法则42 虽落后，别趴下 112
经验法则43 不要落后多久就把原定日期延后多久 122
经验法则44 延误了这个里程碑，一定要按时到达下一个里程碑 123
经验法则45 从延误中学习经验教训 124
经验法则46 要有全局观 124
经验法则47 与时俱进 125
推出阶段 127
推出阶段：启动 127
推出阶段：移交 129
推出阶段：收尾 129
经验法则48 关怀多于要求 130
经验法则49 Beta 版不是修改产品的时候 131
经验法则50 利用Beta 测试来调整宣传策略 131
经验法则51 严格执行类选法 132
经验法则52 小心保持软件的稳定 134
发布阶段 135
经验法则53 伟大的软件应该有一个伟大的故事 136
经验法则54 建立赢家形象 140
结束语 140
附录：聘用和留住人才 142
雇用聪明的人 142
适才适任 144
赛马必须奔跑 144
好高骛远者需要你的推动 145
软件开发领导的一些参考资源 150
第二部分 2006
新的经验法则 154
经验法则55 做完美的老板 154
经验法则56 老板就是你最重要的客户 156
一种更好的方式 157
在如何看待老板上的转变 157
经验法则57 支付木材税和下阿尔法赌注 159
阿尔法（或阿尔法能量） 160
The Core System V. 3.0 的元素 163
形成共同前景的4 个步骤 164
第1 部分：“签到”的元素 164
第2 部分：决策过程的元素 166
第3 部分：校正的元素 168
第4 部分：共同前景的元素 169
The Core Protocols V. 3.0 173
核心承诺 173
核心准则 174
放弃/取消放弃 174
签到 174
离开 175
求助 176
准则检查 177
目的检查 177
决策过程 178
解决 180
完美行动 180
个人校正 181
调查 182
· · · · · · (收起)
读后感
用户评价
对我而言，《软件研发之道》是一本充满智慧的“修行手册”。我一直对软件的“架构”层面感到困惑，总觉得它是一个抽象且难以捉摸的概念。这本书用非常接地气的方式，将复杂的架构设计分解成一个个可理解的模块，并深入浅出地剖析了不同架构风格的优缺点，以及它们在不同场景下的适用性。书中关于“可扩展性”、“可维护性”、“性能优化”等架构设计原则的阐述，不再是停留在理论层面，而是通过大量生动的案例，展示了这些原则如何在实际项目中落地，以及它们对软件长期发展的重要性。我尤其被书中关于“领域驱动设计”（DDD）的介绍所吸引，它引导我如何从业务的视角出发，构建出与业务领域模型高度契合的软件系统。这让我明白，一个好的软件架构，应该能够优雅地应对业务的演进，而不是成为业务发展的阻碍。此外，书中对“技术选型”的分析，也给了我很大的启发。它并非简单地罗列各种技术，而是引导我去思考，在不同的项目背景下，如何权衡各种因素，做出最合适的选择。这本书让我对软件架构有了更深刻的理解，也为我未来的职业发展指明了方向。
一本程序员的启蒙之书，虽然我对书名《软件研发之道》的理解可能与作者的原意有所偏差，但这并不能阻止我被它深深吸引。我一直认为，软件开发不仅仅是编写代码，更是一种艺术，一种哲学。这本书恰恰满足了我对这种“道”的探索。初读时，我被书中对软件生命周期各个阶段的细腻描绘所震撼，作者用一种极其通俗易懂的语言，将那些曾经让我头疼不已的概念，如需求分析、系统设计、编码规范、测试策略，甚至是项目管理，都梳理得井井有条。我尤其喜欢其中关于“低耦合、高内聚”原则的阐述，它不再是教科书上干巴巴的理论，而是通过生动的比喻和实际的案例，让我深刻理解了模块化设计的精髓，以及它如何影响代码的可维护性和可扩展性。书中对“代码即文档”的强调，也让我重新审视了自己撰写注释的习惯，开始注重用清晰、准确的语言来解释复杂逻辑，这无疑提高了团队协作的效率。更让我惊喜的是，作者并没有止步于技术层面，而是深入探讨了软件研发中的沟通、协作以及团队文化的重要性，这对于我这样一位长期埋在代码中的开发者来说，无疑打开了一扇新的大门，让我意识到，一个成功的软件项目，离不开所有成员的共同努力和智慧的碰撞。这本书让我从一个单纯的“码农”蜕变成了一个更具整体视野的“软件工程师”。
读完《软件研发之道》，我感觉自己仿佛经历了一次“重塑”。以前，我总认为技术能力是软件工程师的全部，对项目管理、产品思维这些“软技能”嗤之以鼻。然而，这本书彻底颠覆了我的认知。它以一种非常宏观的视角，阐述了软件研发的本质，并将其与商业目标、用户需求紧密地联系起来。作者在书中提到的“以终为始”的理念，让我开始反思，我们开发的功能究竟是为了解决什么问题？它是否真正为用户创造了价值？这种转变，让我不再是机械地执行任务，而是开始思考“为什么”和“为了谁”。书中关于“敏捷开发”的实践，也让我耳目一新。它不再是模糊的口号，而是通过具体的流程和方法，如迭代开发、持续集成、频繁发布，帮助我理解如何在快速变化的市场环境中，高效地交付高质量的软件。我尤其欣赏书中关于“团队赋能”的论述，它强调了给予团队成员充分的自主权和信任，激发他们的创造力，从而提升整体的交付效率和士气。这本书让我认识到，一个成功的软件项目，不仅仅是技术的堆砌，更是团队协作、产品愿景和市场洞察力共同作用的结果。
这本《软件研发之道》就像一位循循善诱的导师，它没有直接给我答案，而是引导我去思考，去探索。我曾经以为，只要技术过硬，就能成为一名优秀的软件工程师。但这本书让我意识到，优秀并非仅仅是代码的优雅，更是对整个软件生命周期的深刻理解和有效管理。书中关于“持续学习”的理念，让我深刻认识到，技术日新月异，唯有不断学习，才能跟上时代的步伐。作者鼓励读者保持好奇心，勇于尝试新的技术和方法，并从中吸取经验。我开始有意识地关注业界最新的技术动态，并尝试将其应用到自己的项目中。书中对“项目风险管理”的讲解，也让我受益匪浅。它让我学会如何识别潜在的风险，并提前制定应对策略，从而避免项目陷入困境。此外，书中关于“代码审查”的建议，也让我重新审视了团队协作的重要性。它不仅仅是为了发现bug，更是为了促进知识的共享和技术的进步。这本书让我明白，软件研发是一场马拉松，而非短跑冲刺，唯有持之以恒，不断精进，才能最终抵达成功的彼岸。
我常常在想，究竟是什么让一些软件项目能够历久弥新，而另一些则昙花一现？《软件研发之道》这本书，就像一位经验丰富的老者，为我拨开了眼前的迷雾。它没有惊天动地的理论，也没有晦涩难懂的术语，而是将焦点放在了那些看似微不足道，却又至关重要的实践细节上。我至今还记得书中关于“重构”的章节，它并没有简单地教我如何改变代码结构，而是引导我去思考“为什么”需要重构，以及在什么时机进行重构。作者用大量的篇幅阐述了“技术债务”的概念，并提出了切实可行的管理策略，这让我幡然醒悟，原来那些曾经因为急于求成而留下的“烂摊子”，正在悄悄地吞噬着项目的生命力。书中对“测试驱动开发”（TDD）的介绍，也让我受益匪浅。它不再是理论上的口号，而是通过具体的代码示例，展示了如何从一个简单的测试用例开始，逐步构建出健壮、可靠的代码。我开始尝试在自己的项目中应用TDD，虽然起初有些不适应，但很快就体会到了它带来的好处：更少的bug，更清晰的设计思路，以及更高的开发信心。这本书让我明白，软件研发并非一蹴而就，而是一个持续优化的过程，每一个细小的改进，都在为项目的长远发展添砖加瓦。
翻译一般 不知所云
最后的关于核心协议/准则v3.0的说法让我很不得要领。。。
翻译一般 不知所云
写<走出软件作坊>的阿朱反复提到的一本书，但只能说真的不是我的菜，整本书的看目录就够了
书名更改为软件研发管理之道更为合适，翻译一般。软件=团队，软件研发的关键在于构建一个高效的自组织团队是按时交付的关键。最后的核心准则v3.0重点突出了一些团队合作的沟通原则，值得借鉴，其他章节可略。
