推荐一本“老”书——硝烟中的 Scrum 和 XP，有额外的推荐点：产品与开发的关系、可持续的工作时间

[passerbytiny]

主题

书籍信息：

• 硝烟中的 Scrum 和 XP （ infoQ ）
• 硝烟中的 Scrum 和 XP （清华大学）

核心推荐点：

• Scrum 实践。
• 众多实践要素，能帮助人区分“快”和敏捷。

额外的推荐点：

• 时间估算是开发团队独有的权利，故事重要性是产品负责人独有的权利。
• 如果产品负责人想当甩手掌柜，就整死他（见摘录）。
• 一天 = 6 小时，实践说明加班起负作用（见摘录）。

感概

一直以为敏捷开发在大多数时间里都是探索阶段，最近才通过 Scrum 等进入了大范围实践，现在发现自己错了。这本书翻译版本是 2008 年出版的，可能是 2006 年编写的，而当时作者已经有了至少一年成功的 Scrum 实践。现实的情况很可能是：2006 年 Scrum 已经证明很好了，然而大公司因为体量太大只能慢慢转换，最近才完成标志性的转换（ Win10 更换发布计划、Java 更换发布计划……）。

---

摘录内容一

有时候产品负责人会不太情愿跟团队一起花上几个小时制定 sprint 计划。“嘿，小伙子们，我想要的东西已经列下来了，我没时间参加你们的计划会议。”这可是个非常严重的问题。
...
在某些情况下，团队对故事做出的时间估算，跟产品负责人的想法不太一样。这可能会让他调整故事的重要性；或者修改故事的范围，导致团队重新估算，然后一连串诸如此类的后续反应。
如果产品负责人还是坚持没时间参加怎么办？一般我会按顺序尝试下面的策略：

...
推迟 sprint 的启动日期，直到产品负责人找到时间参会为止。同时拒绝承诺任何交付。让团队每天都可以自由做他们最想做的事情。

摘录内容二

在讲述 Scrum 的书和文章中，大多数都是用小时而不是天数来估算时间。我们也这样干过。我们的通用方程为1 个有效的人-天=6 个有效的人-小时。

很多有关敏捷软件开发的书都声称：加班工作在软件开发中会降低生产率。
经过几次不情愿的试验之后，我完全拥护这种说法！
大约一年以前，我们中有一个团队（最大的团队）在疯狂加班。现存代码库的质量惨不忍睹，他们不得不投入绝大多数的时间来救火。测试团队（同样也在加班）根本没时间来认真地做质量保证工作。我们的用户很生气，小道流言也快把我们活活吞掉了。
几个月后，我们成功地把大家的工作时间缩短到了适当的范围。他们正常上下班（除了有时候在项目关键期要加班以外）。令人惊异的是，生产率和质量都取得了显著提高。
当然，减少工作时长绝不是带来改进的唯一因素，但我们都确信它的影响很大。

[passerbytiny]

结束语摘录：

哦，最后请不要忘记......

这只是一份工作而已，不是么？