一. 莫把“承诺”当“保证”
在实施Scrum的过程中，许多团队在确认迭代目标时表现得非常谨慎和保守，他们担心如果实现不了迭代目标会遭受处罚。在某些组织中，我曾经听到某些管理者说出类似这样的话——“既然承诺了，就一定要兑现”、“如果做不到，为什么要承诺”、“如果承诺的东西都兑现不了，那么承诺有何意义”；同时，我也发现开发团队心存恐惧——担心因为承诺兑现不了，而被管理层看低甚至遭受处罚。
“承诺”是Scrum的核心价值观之一。然而，这些组织把“承诺”当成了“保证”，这就出问题了。
如果把“承诺”当成“保证”，通常可能会带来以下一系列问题：
首先，开发团队会抗拒接受挑战性的迭代目标。在把“承诺”当“保证”的组织中，开发团队会拒绝接受挑战性的迭代目标，因为他们可能会因此而受到伤害。因此，在这些组织中，确认迭代目标时，开发团队会倾向于做最悲观的估算，并且只愿意承诺自己绝对能完成的工作。
第二，团队会在估算和迭代计划上投入更大的管理成本。为了控制风险，团队会在迭代前投入过多的精力来了解需求和方案细节，以期计划得更为准确。这样一来，就拉长了迭代准备和计划的时间，以及加大了管理成本的投入。
第三，破坏开发团队与PO之间的信任关系。在业务交付压力不大时，PO尚能容忍开发团队的“保守”作风。一旦面临巨大的业务交付压力时，PO就会对开发团队心存芥蒂，会向开发团队大声抱怨，甚至会向管理层投诉，而这又进一步引起了开发团队对PO的不满。双方彼此不再信任，甚至可能会走向对立和冲突。
第四，破坏开发团队与管理层的信任关系。当开发团队持续表现得“保守”时，管理层会认为开发团队没有“进取心”和“战斗力”，这会导致管理层不再信任开发团队。
最终，“自组织”的管理文化和管理方式会被抛弃。在业务交付压力下，忍无可忍的管理层会选择插手迭代目标计划和迭代过程管理。这样一来，变成了管理层和PO向开发团队强加迭代目标和管理迭代工作。至此，“自组织”的文化和管理方式已经被组织抛弃，组织重新回到了传统的、以管理者为核心的管理文化和管理方式上。
所以，万万不可把“承诺”当“保证”。
二. 该如何理解和实施“承诺”
那该如何理解和实施“承诺”？
不能简单而孤立地理解和实施“承诺”，而是应该综合Scrum的全部价值观，去理解和实施。我认为：“真正的承诺”=“有相当把握”+“拼尽全力”+“过程透明”：
首先，开发团队对于迭代目标能否实现，应该是“有相当把握”的。如果开发团队不重视承诺，经常不能兑现其承诺的迭代目标，这会导致业务人员无法制定工作计划，这也会破坏开发团队与PO的信任关系。但是又不能完全不冒任何风险，否则就会导致迭代目标制定得过于“保守”。所谓“有相当把握”，应该是开发团队觉得自己应该能完成，但是偶尔又可能会出现偏差。Mike Cohn曾经把它比喻成篮球运动员投篮：除非球员感觉能投进球，否则就不应该投篮；但即使是最伟大的球员也不能保证每次都能投进球。从结果上来看，“有相当把握”意味着大部分迭代能达成迭代目标，但是仍有少数迭代可能会达不成迭代目标。在统计数据上看，能达成目标的迭代比例在80%左右，可能是比较合适的——这既能保证工作有足够的挑战性，也能支撑业务工作有足够的计划性。
其次，开发团队应该在迭代中“拼尽全力”。在迭代中，开发团队应该聚焦迭代目标，并尽早地实现迭代目标。当迭代目标可能达不成时，开发团队应当想尽各种办法、通过各种努力来竭力做到最好（并不能保证一定实现）。当然，所谓“拼尽全力”是有限度和范围的，并不意味着就需要开发团队天天加班到很晚，去搞“996”甚至是“007”。短期冲刺性的加班，能够在一定时间段内加大业务交付量；但是长期无节制的加班，只会导致开发团队身心疲惫，进而导致交付和质量双双下降。
第三，开发团队应当做到过程透明。在迭代中，开发团队应当向PO和管理层透明迭代目标的实现进展。当出现意外时，开发团队应当及时向PO和管理层透明问题和风险，并告知可能会造成哪些迭代目标无法完成。
只有这样，开发团队的“承诺”才能真正得到PO和管理层的信任。
三. 度量但不要考核“迭代目标达成率”
大部分组织都会对开发团队进行绩效考核。我想提醒大家的是：可以度量“迭代目标达成率”，但绝对不要将其作为考核指标。
度量“迭代目标达成率”是有意义的，能帮助了解团队的迭代目标计划和实现能力，为持续改进提供有价值的输入。但如果把“迭代目标达成率”作为开发团队的考核指标，就会导致“承诺”变成“保证”，进而可能引发前面提到的一系列问题。
四. 您怎么看
您是如何理解Scrum的“承诺”价值观的？在您的组织中，存在把“承诺”当成“保证”的现象吗？
欢迎在评论区留下您的观点。
本文作者：
李洁（Jerry Li），CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练
