书籍介绍
这本书最锋利的地方，在于它把'谁来写代码'这件事重新摆到了台面上。当软件工程承诺'定义好过程，任何人都能造出好软件'时，作者却指出：真正决定项目成败的，是作为个体的程序员的技能、经验与责任。读者反复提及的'开发回归人本''充分发挥人的作用'，正是这一主张的核心。书中对'足够好的软件'的流行做法、编码与测试强行分离、需求反复变更背后的学习成本，都做了不留情面的剖析。它适合那些对'流程万能论'感到怀疑、愿意重新思考开发者与作品、与客户关系的从业者；也适合管理者反思'教练拿明星薪水'的荒诞。当然，也有读者嫌它啰嗦、过时、'好像没说太多'——这些争议本身，正是它值得一读的理由。
作者简介
PeteMcBeen是一位独立顾问，对软件开发情有独钟。尽管将很多时间用于写作、教学和顾问工作，但他仍然坚持每年至少在一个真实项目中亲手从事编程工作。Pete特别善于为软件开发者面临的问题找到创造性的解决方案。在过去的很多年中，他参与了各种正式与非正式的过程改进活动，所以他能够以超然的态度看待软件业普遍存在的问题，并敏锐地意识到：“软件开发理应有其乐趣。否则，开发过程就是错的。”Pete住在加拿大亚伯达省的小镇考昆，没有再回到大城市居住的计划。
AI导读
核心看点
- 质疑软件工程万能论，主张以工艺学视角重构开发
- 强调开发者个人技能与责任感，反对过度流程化
- 区分工程与工艺适用场景，提倡小规模协作交付
读者共识
- 颠覆传统认知，强调人的因素优于僵化流程
- 部分观点被认为过时，但核心思想仍具启发性
- 适合小型团队参考，大型项目需结合工程方法
精彩摘录
- "一个非常典型的例子就是美国国防部于 1969 年至 1975 年间开发的 SAFEGUARD 弹道导弹防御系统。“SAFEGUARD 系统的开发和部署堪称有史以来最大、最复杂的软件系统。”在项目开始的第一年（1969 年），工作量为 188 人年；到 1972 年，年工作量已经达到 1 261 人年；整个项目的工作量共计 5 407 人年，平均每年生产率为每人年 418 条指令。 SAFEGUARD 是一个极其庞大的软件工程项目，它也代表了当时软件工程的最高水平。它所使用的计算机硬件是专为此项目而开发的。尽管程序设计工作都是用低级语言完成的，但编程和单元测试阶段在全部工作量中所占的比重还不到 "
- "如果在一只运动队中，教练拿着比明星球员们还高的薪水，你认为这支球队能维持多久？"
- "软件工程的关键问题就在于：它使我们忘记了“是人来开发软件”这样一个简单的事实。软件工程含蓄地给了我们一个承诺：只要能定义出一个有组织、有纪律、可计量的开发过程，任何人都可以成功地完成软件开发。可惜，这只能是一个梦想。正如 Curtis 的调研报告所表明的：就算有了一个理想的过程，想要获得项目的成功，出类拔萃的开发者仍然是必不可少的。 越好的程序员，所犯的错误就越少，并且发现错误也越快。 真正决定项目成败的，是作为个体的程序员的技能、知识和经验。 其实，我们应该讨论的不是“项目的缺陷可能性”，而是“开发者的缺陷可能性”。"
- "SCRUM 软件开发过程的创始人曾经这样说道： 如果某个过程能够完全确定下来（即能够了解过程所涉及的所有细节，从而将其设计为可以重复地多次运行，并且完全能够预测其结果），那么该过程就被称为“确定过程”。从理论上来说，一切确定的过程都可以被自动完成。另一方面，如果人们并未了解某个过程中的所有细节，只是大致地知道在某些初始条件下、通过某些调节和控制就能得到想要的结果，这样的过程就被称为“经验过程”。"
- "开发者哪怕只是动一动“排除所有缺陷”的念头也会被认为是浪费力气，因为一大半的特性很可能就实现在现有的错误之上。由于“足够好”的开发方式将编码和测试分离成了两个截然不同的阶段，所以用这种方式开发出的应用程序中必定会包含大量缺陷。"
- "软件开发的整个过程可以总结为：获取明确的和隐含的知识，并将这些知识具现化到软件之中。按照 Howard Baetjer 的观点，软件开发者的关键难题在于协调各种不同知识的学习，软件开发的关键局限在于“理解我们尝试做的事情的能力”。 特别是，客户也需要经历一个学习的过程，听项目组向他们解释需求所蕴涵的本质。这个学习的过程正是造成需求变更的一个主要原因。 软件开发的全部意义就在于解决未知因素。"
- "在软件开发史的早期，情况并非完全如此，因为当时的最大困难是在实现阶段，也就是“如何给计算机编程”的问题。但是，随着开发者们逐渐创造出越来越好的编程方式，困难就逐渐从实现阶段转移到了设计阶段。而对于如今的很多项目来说，设计和实现都已经不再是难题，最主要的困难是在需求分析阶段和需求分析与软件设计之间的交流上。"
- "我发现项目进度的瓶颈竟然如此变化不定，这一发现一直都令我非常惊讶。可能成为瓶颈的步骤包括： 谈判认可项目预算； 选择合适的开发团队（尤其是在进行外包时）； 获取需求文档并签字认可（这一过程也许会长达 7 年之久）； 与业务用户和决策者交流； 由项目指导委员会及时作出决策； 找到优秀的设计师和程序员； 通过与并行项目的竞争而获得项目所需的资源； 当有经验的开发者不得不抽出时间来指导新手时，他需要腾出时间完成被耽误的工作； 让技术选择得到批准和签字认可； 在各种各样的交付平台上测试； 让应用体系结构组认可整体设计概念； 使主要的开发者达成共识，选择合适的设计方案； 安排设计和代码复审的时间表； 调"
目录
用户评论
运维又难做又被看轻，这是错误的。系统联调的时间开销占到了40%，深有同感。编码是软件开发中最容易的部分。嗯。
在这个商业资本统治一切的时代，文中观点难以尽行。但这种理想主义情怀，却是推动软件行业进步所必须，愿为之贡献自己的一分力。
使用工艺学来暗喻软件开发，看前几部分内容以为是反软件工程的思想，但第4部分阐述软件工艺是对软件工程的补充，软件工程适合的是那些庞大的需要100人年以上的项目而工艺学方法时候小型需要快速交付的项目。其中一些关于学徒，专业培训，客户沟通的观点很中肯。原本2个晚上可以读完的，拖了好久，今晚一狠心读完了，受益匪浅
过时了，不推荐了
小开本好棒！这本书从头到尾都在婊软件工程的概念，力推类比于传统行业的“工艺”思想。里面也确实找到了很多之前和现在碰到的问题。但很可惜，大部分这些问题的始作俑者是不读这书的。
这本书的内容让我联想到了两样东西：一个是知乎上一篇答案提到的，不同职级开发职责工作内容高度重合、然而负责的问题权重不同的分配方式，个人觉得非常可取；另一个是现在很多越来越臃肿、净多些有的没的花里胡哨的很多APP（名我都不用点，太多了，其中某常用网购平台APP还被我老爸经常骂用户体验越来越差）。这种断裂式分工的、大批人走大批流程快糙猛搞“大生产”的开发方式就一定是没得选的、一定是默认的、一定是对的、一定是好的吗？
P.S. 我虽然认同“软件工艺”的不少观点，不过也对它抱有一些警惕的态度。作为个人，我对“工程师”和“工匠”身份的认同都不强烈（也在保持一定的距离），不如说我只是想尽量做好比较喜欢的手头活计，也不想给自己框定一种什么身份。
高度同意书中大部分观点，软件工艺充分发挥人的作用
就是太啰嗦
求书
收藏