我看“不做不该做的事情”比“做该做的事情”更重要，至少是一样重要。最要不得的是“六拍项目”：拍脑袋、拍肩膀、拍胸脯、拍桌子、拍屁股、拍大腿。

– 最近在看《人人都是产品经理》，后面慢慢谢谢心得。

俩说相声的，一左一右，一捧一逗，这叫分工。上台前俩人商量商量今天加点儿什么新包袱，台上谁出了纰漏对方麻利儿给兜着，这叫合作。

如果台下俩人不说话，出了纰漏不兜着不说还埋怨对方没做好自己工作，那就只是分工，不是合作。

所以合作必须要分工，但有了分工不一定就合作好了，还差很远呢。得俩人同心同德的想着把台下的观众逗乐了，别只想着自己那几句写在本儿上的词儿。

KPI制定的时候也要考虑避免只分工不合作的情况出现。最好KPI本身就能促使两人合作，比如把他们变成一条绳子上的蚂蚱。

五原则：覆盖率、重点突出、可实现、有所成就、可检查。对你定出的kpi用这五个原则Review，如果每个原则都达到了，那么这个KPI应该不离谱。

• “覆盖率”说的是KPI覆盖了你所关注的重点工作。不用每个工作都有KPI管着，但重点工作不要有漏掉的。
• “重点突出”和“覆盖率”对立，说的是4、5个KPI项不是均等的，一个人一段时间能有2个重点工作不错了，比如给出重点的KPI。
• “有所成就”说的是如果KPI定完了，自己看着这些KPI都提不起工作的兴趣，那么还是找你的老板推倒重做吧。总得做有挑战、有价值、有趣味的工作吧。
• “可实现”和“有所成就”对立，说的是KPI要可以做得到，一个高不可及的KPI只能起到挫伤工作积极性。
• “可检查”说的是指标要能清楚的计算出来，最好每天、每周都能检查KPI完成情况。

关于KPI制定的“原则”很多吧？其实还不止这些呢，写出来会显得太絮叨了。一个好的KPI一定要能经得起这些原则的考察。知易行难。

1. 可以让人读的非常开心。全书净是下面这样风格的话语：“听起来不错？呵，纯粹扯淡。更糟的是，团队一般都是到了会议结束前才发现他们一直在扯淡，到最后还没把故事看上一遍呢！”
2. 非常实际。这本书就是作者在一个4、50个研发人员的团队中1、2年（2005年下半年到2007年初）的时间实践Scrum和XP的总结，所以其中有很多实际的经验、教训、建议，很细节。

好了，下面是读书笔记，同样如果对于XP或者Scrum的基本名词没有概念的，简单Google一下就好了，了解一下名词和概念就好，别读太多理论读物。

“Scrum的强大和令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整。。。。一年过去了，我们在公司里从上到下都实现了Scrum。我们试过多种团队尺寸（3-12人）、sprint长度（2-6个星期）；定义“完成”的不同方式；不同形式的产品backlog和sprint backlog（Excel、Jira、索引卡）；多种测试策略、演示方式、多个Scrum团队的信息同步方式……。我们还试验了XP实践——各种各样的每日构建，结对编程，测试驱动开发，等等；还试过把XP和Scrum进行结合。”

– 我深信“持续改进”“自我完善”这是任何一个开发过程中最重要的理念。幸运的是Scrum把过程持续改进作为了其执行的一个内在环节。

“产品backlog是Scrum的核心，也是一切的起源。我们叫它故事（story），有时候也叫做backlog条目。我们的故事包括这样一些字段：ID、Name、Importance、Initial Estimate、How to demo、Note。我们曾试过很多字段，但最后发现，只有上面提到的六个字段我们会一直使用下去。”

– 很简单是吧？简单就对了。把那么多功夫花在这些事情干什么，有空编码去好不好！

“Sprint计划会议非常关键，应该算是Scrum中最重要的活动（这当然是我的主观意见）。要是它执行的不好，整个sprint甚至都会被毁掉。”

– 在Scrum开发过程中“项目会”是那么的少，所以我也相信“Sprint计划会”是Scrum中最重要的活动。

“Sprint计划会议会产生一些实实在在的成果：

• sprint目标。
• 团队成员名单（以及他们的投入程度，如果不是100%的话）。
• sprint backlog（即sprint中包括的故事列表）。
• 确定好sprint演示日期。
• 确定好时间地点，供举行每日scrum会议”

– 我认为“确定好Sprint演示日期”这个最刺激，呵呵。

“假如sprint计划会议接近尾声，但仍然没有得出sprint目标或者sprint backlog，这时该怎么办？我们要打断它么？还是再延期一个小时？或者到时间就结束会议，然后明天继续？这种事情会一再发生，尤其是在新团队身上。你会怎么做？我不知道。但我们的做法是什么？嗯……我通常会直接打断会议，中止它。”

“几乎每次sprint计划会议都要确定sprint目标。Sprint目标需要回答这个根本的问题，“我们为什么要进行这个sprint？为什么我们不直接放假算了？””

“在大多数sprint 计划会议上，大家都会讨论产品 backlog中的故事细节。对故事进行估算、重定优先级、进一步确认细节、拆分，等等都会在会议上完成。
我们是怎样实际操作的呢？要想收到好的效果，不妨创建一些索引卡，把它们放到墙上（或一张大桌子上）。”

– 一个Backlog一张纸质卡片，听起来不错，很直观，又让大家获得几个小时离开电脑的时间。

“在sprint演示会议上，团队自豪地演示了一个新特性，但产品负责人却皱起眉头，“呃，看上去不错，但这不是我要的！”发生这种事情可真是糟透了！
怎样才能让产品负责人和团队对故事有同样的理解？或者保证所有的团队成员对每个故事都有同样的理解？嗯，这可没法做到。不过还是有些简单技术，可以识别出最明显的误解。最简单的办法就是确保每个故事的所有字段都被填满”

“注意——我们在实践TDD（测试驱动开发），所以几乎每个故事的第一个任务都是“编写一个失败的测试”，而最后一个任务是“重构”（提高代码的可读性，消除重复）。”

– 我们不做TDD，但把“重构”作为最后一个任务也是不错的哈。

“这有个很复杂的问题：技术故事。或者叫做非功能性条目，或者你想叫它什么都行。例如：安装持续构建服务器、重构DAO 层、升级 Jira”

– 这段太长了，但这个问题太重要，很多技术经理都非常关注，所以还是看原文去吧。在P54

“我们要让整个公司了解我们在做些什么，这件事情至关重要。否则其他人就会发出抱怨，甚或对我们的工作做出臆断。”

– 这段也太重要了！但是也太长，归纳一下就是：一个展示项目信息的网页、sprint开始和结束都群发邮件、将Sprint信息打印出来贴到开发团队墙上。

“我们发现管理sprint backlog最有效的形式——挂在墙上的任务板！
找一面尚未使用或者充满无用信息（如公司logo、陈旧图表或者丑陋的涂鸦）的大墙。清理墙壁（除非不得已才去请求别人许可）。在墙上贴上一张很大很大的纸（至少2×2平方米，大团队需要3×2平方米）。然后这样规划：。。。。。”

– 又是“纸质”的东西，嗯，我喜欢纸质的和写在白板上的。原因嘛，还是它可以让我远离电脑，呵呵。

“嘿，该怎样进行跟踪呢？在这种模型中，如果必须跟踪的话，那我能提供的最佳方式，就是每天给任务板拍一张数码照片。我有时也这样干，但一直没用到这些照片。如果你确实需要跟踪任务进度，任务板这种解决方案可能就不太适合你。
不过我建议你应该试着去评估一下，对sprint进行细节跟踪能带给你多大价值。Sprint完成以后，可以工作的代码已被交付，文档也被check in，那还有谁会真的关心sprint的第5天完成了多少故事呢？又有谁会真的关心“为Deposit编写失败测试”曾经的估算量是多少？”

– 我很同意。一个Sprint只有2、3周的时间，这期间的事情让项目组内部自己搞定吧，外部的人那么不放心干什么。

“在安排座位、布置桌椅这方面，有一件事情怎么强调也不为过。
让团队坐在一起！
说的更清楚一点，我说的是
让团队坐在一起！”

“我们的每日例会跟书中的几乎没啥两样。它们每天都会在同一个地方，同一个时间进行。一般我们都是开站立会议，以防止持续时间超过15分”

– 我也喜欢站着开会，可以活动一下身体。当然，也能远离电脑。

“一定要做Sprint演示。让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”。不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。把那些玩意儿扔一边去，集中精力演示可以实际工作的代码。”

“在有关回顾的种种一切中，最重要的就是确保回顾能够进行。由于某些原因，团队常常都不太愿意做回顾。如果不给他们点温柔的刺激，我们的大多数团队都会跳过回顾。说句实话，我认为回顾是Scrum中第二重要的事件（最重要的是sprint计划会议），因为这是你做改进的最佳时机！”

“Sprint之间的休整。我们会力求保证不在同一天举行sprint回顾和下一个sprint计划会议。”

“在绝大多数层面上组合使用XP与Scrum，我们都已经尝试过了。有些XP实践直接被Scrum解决掉了，可以被视作二者的重叠。如“整体团队”，“坐在一起”，“故事”和“计划游戏”。在这些情况下我们就直接使用了Scrum。
我们近来开始在一个团队中实施结对编程。效果相当好。虽然其他团队大多数还没有进行太多尝试，但在一个团队中使用了几个sprint之后，我已经有了很高的热情去指导其他团队进行试用。”

“测试驱动开发（TDD）阿门！对我来说，它比Scrum和XP还要重要。你可以拿走我的房子、我的电视还有我的狗，但不要试着让我停止使用TDD！”

–嗯，我还真没做过TDD

“学到的一课：如果你深陷手工回归测试的泥潭，打算让它自动化执行，最好还是放弃吧（除非做起来特别简单）。首先还是应该想办法简化手工回归测试。然后再考虑将真正的测试变成自动化执行。”

“我们在实施Scrum的时候，所做的第一件事情就是打乱特定于组件的团队（方式1），创建跨组件的团队（方式2）。它减少了诸如“我们没法完成这个条目，因为我们在等server那帮家伙完成他们的工作”之类的情况发生。不过，要是有很强烈的需求，我们也会临时创建针对特定组件展开工作的团队。”

– 嗯，我也喜欢让一个团队内部搞定尽可能多的事情。跨团队沟通就是麻烦

“每周的全体（嗯，所有参与开发的人）会议。时长15分钟。
什么？15分钟？全体参加？每一个产品所包括的全部团队中的所有人都会参加？这能行么？
是的，能行。只要你（或是其他主持会议的人）严格限定会议的时间不要过长。”

– 开大会，挺好的。信息要在团队中充分共享嘛。

最后总结一下在实施scrum的团队中的会议有哪些：

• Sprint计划会（4小时）
• Sprint日例会（15分钟）
• Sprint演示会（30分钟？）
• Sprint回顾会（1、2小时）
• 研发部周例会（大会）（15分钟）