书籍介绍
这不是一本讲如何把项目计划做得漂亮给管理层看的书。它真正关心的，是那个每天被各种声音打扰、进度说不清、团队各自为战的实际项目。作者把大量篇幅给了'如何保护团队'：用任务清单、每日站会、代码审查、自动构建这些看似枯燥的习惯，挡住无会议、乱特性和'我这里没问题'式的混乱。书里甚至直言'总线数'——信息只压在一个人手里，项目就悬了。它适合那些接手了烂摊子、被遗留代码缠身、或正被'另类开发人员'和'死亡之旅'项目折磨的人。争议也在于此：它的方法高度依赖桌面开发经验，嵌入式场景未必适用。但正是这种不粉饰的务实，让它更像一本救急手册，而非成功学。
作者简介
Jared R. Richardson是一名开发人员、演说家、作家和独立顾问，是由开发人员逐步成长为研发经理的。他有着十多年丰富的工作经验，擅长使用非定制技术来解 决疑难问题。他领导着SAS软件研究所的一个开发和测试团队，负责带领整个公司提高了测试自动化的使用。
William A. Gwaltney Jr.有着二十多年软件开发经验，在网络、通信、知识表达及基于网络的计划调度方面都很有造诣。他在SAS软件研究所从事测试自动化方面的工作。
AI导读
核心看点
- 涵盖工具、曳光弹开发及常见问题解决
- 提供大量实用技巧，帮助快速消化内容
- 以精炼风趣语言揭开项目管理神秘面纱
读者共识
- 内容非常务实，适合入门阅读
- 道理易懂，但实际落地执行困难
- 善用工具与习惯养成是成功关键
精彩摘录
- "技术领导人要完成的工作： 确保团队的工作优先级与客户的需求一致； 确保将团队的工作适当地展示给管理层； 将团队与不懂技术的管理层隔离； 为不懂技术的干系人解释技术问题； 让开发团队了解非技术问题。 技术领导人的职责： 为团队成员设定方向； 管理项目的特性列表； 为项目的特性确定优先级； 隔离你的团队，使他们不受外部干扰。 技术领导人应该能够顺利回答的问题： 你知道团队的每一个成员都在做什么吗？ 你能不能在5分钟内生成一个关于项目状态的总结？ 产品接下来要事先的5到10个特性是什么？ 你能不能很容易地列出产品中优先级最高的缺陷？ 你为团队成员解决的最近的问题时什么？ 如果一个团队成员需要解决一个"
- "集体参与架构设计： 1.一个会议主持人，任何人说话之前必须经他“许可” 2.整个会议中应在白板上记录要点 3.可以用LEGO或积木表示系统中的对象 4.记录接口并发布。 5.保证会议不被中断。要尽量减少转移话题和回答问题的次数。 增加总线数： 总线数是指当损失的开发人员达到这个数，则极有可能导致项目失败。如果你的团队有一个“超级明星”，项目大部分信息都在他手里，那么你的团队总线数就是1。 曳光弹开发流程： 提出系统目标->提出接口->连接接口->增加功能->重构、求精、重复->提出系统目标（新目标）->...如此重复 工作流程： 1.定义系统对象。 2.定义系统对象间的接口。 3.编写接口桩。"
- "千万不要工作两天以上而不做一次代码审查 维护遗留代码： 构建 自动化构建 模拟用户功能测试 单元测试 测试之前不要修改遗留代码 尽早而且经常发布真实演示系统。 另类开发人员：与团队步调不一致，经常造成破坏但坚信自己是正确的。 使用每日站会修正另类开发人员的航向 保证另类开发人员只能完成任务清单上的任务 使用代码审查和自动代码变更通知来追踪另类开发人员的工作 使用CI来作为最后一道防线监视另类开发人员的工作 如何有效的与你的经理沟通： 制定团队任务清单和个人任务清单，定期（例如每2周）让经理审查 让经理（例如每周）掌握团队和你的最新进展（例如邮件） 如果遇到每天检查你好几遍的老板，则给他看任务清"
目录
用户评论
实用，中肯。自动化工具不仅提高效率，还可以纠正很多开发过程中难以发现的错误。
一些细节有些用，不过大部分已经是行业惯例了
项目管理与自我管理无非都是“习惯”二字而已
读了2遍，用这本书开启了对软件项目这个领域的学习。多读几本书，多实践后回头再读，收获应该更大。
需要重新养成四五年前的习惯，比如每日的 stand-up meeting，团队的 todo list 等等
Out of date. No longer recommended.
从实践角度介绍了各种方法和工具，对于不那么规范的团队还是非常有意义的，工具和方法是软件开发效率和质量的基石。
代码版本控制，bug记录，自动化测试，任务清单确实都是要认真落实的！
