第11章 测量并监控速率
-
迭代式发布计划：这是指将项目划分为一系列短期迭代的做法。每个迭代通常持续数周，团队会选择并完成一定数量的故事点（或用户故事）作为目标。这种方法允许团队在每个迭代结束时交付具体功能，从而实现渐进式开发和交付价值。
-
故事点：故事点是一种用于估算任务复杂度和工作量的相对度量单位。团队会根据任务的复杂程度、不确定性和其他因素来给任务分配故事点，而不是使用时间单位（如小时或天数）。这种相对估算更侧重于任务复杂性，而不是时间，有助于更好地理解和规划工作量。
-
速率：在敏捷项目管理中，速率是指团队在每个迭代中完成的故事点数。通过追踪每轮迭代完成的故事点数量，团队可以计算出他们的速率。这有助于预测团队未来工作的能力和时间。稳定的速率表示团队已经形成了一种相对可靠的工作节奏。
-
测量速率的重要性：速率是一个重要的度量指标，能够帮助团队更好地规划和预测未来的工作。通过了解团队的平均速率，项目经理可以更准确地估算未来迭代中可以完成的工作量，并调整发布计划。
-
计划速率和实际速率对比：这是一种监控团队工作效率的方法。团队会设定计划速率（预期完成的故事点数量），然后在每个迭代结束时，对实际完成的故事点数量进行比较。这种对比有助于识别团队的生产率和效率，并可以在必要时采取措施来改进工作流程或调整期望。
第12章：故事的真谛
在这一章中，作者着重强调用户故事与IEEE830软件需求规格的不同。作者认为IEEE830的需求规格过于关注检查清单，而不是用户的实际目标。相比之下，用户故事更注重用户的目标，而不是形式化的规格。
一个典型的IEEE830需求规格以清单的形式呈现，就像你的脑中可能是一台汽车一样。作者指出，这样的规格容易使项目偏离轨道，因为它们过于关注需求的具体表述，而忽略了用户的整体目标。相反，用户故事更注重用户的期望和目标，使得对产品有一个更全面的理解。
用户故事与用例也有明显的区别。用例是对一个或多个用户之间交互的一般性描述，而用户故事更加侧重于具体用户的需求。故事的范围相对较小，通常不超过10个开发工作日，与用例的广泛描述形成对比。
另一个区别在于故事的寿命，它在迭代完成后可以被撕毁，而用例通常是永久性存在的。故事也更加灵活，不容易陷入过早的界面设计细节，这有助于在项目早期避免问题。
用户故事还不同于交互设计场景。交互场景通常比用例更为详细，包含应用环境、角色、目标和行动等元素。相比之下，用户故事更侧重于用户的期望和目标，而不涉及如此多的细节。
第13章：故事的优势
这一章深入探讨了用户故事的优势。首先，用户故事强调口头沟通，使得所有团队成员更容易理解和参与。由于用户故事着重于用户的期望和目标，每个人都能够理解故事的重要性，从而促进更好的团队合作。
用户故事的大小适合做计划，因为它们通常较小，可以在较短时间内完成。这种大小的故事也适合迭代开发，使得团队可以更灵活地应对变化和调整计划。
延迟细节是用户故事的一大优势。相比于过早考虑界面细节或其他具体实现，用户故事更注重用户期望和目标，这有助于保持开发的灵活性。
用户故事还支持随机应变的开发，因为它们可以在每个迭代中进行调整。这种灵活性有助于项目更好地适应变化和客户需求的变动。
参与性设计是用户故事的另一个优势。由于故事着重于用户期望，团队成员更容易参与到设计和讨论中，从而产生更好的解决方案。
用户故事还有助于传播隐性知识。通过讲述用户的期望和目标，团队成员可以更好地理解项目的上下文和用户需求。
第14章：故事的不良征兆
在这一章中，作者探讨了一些用户故事的不良征兆。首先，故事太小可能会导致估算的不准确性，因为它们可能需要不断调整。作者建议将过小的故事合并，以确保更准确的计划。
故事相互依赖可能会导致迭代计划的困难。作者指出，依赖关系过多会使得项目进度难以把握，因此需要注意避免故事之间的过度依赖。
"镀金"是另一个问题，指的是开发人员在迭代中实现了计划外的功能。作者建议通过每日会议提高任务的可见性，以更好地控制项目的进展。
细节过多也是一个问题，因为花费太多时间在故事的书写上，而不是在讨论和实际开发上。作者建议在写故事时保持适度的细节，以避免陷入繁琐的过程。
过早考虑用户界面细节是另一个警告，因为在项目早期阶段过多关注界面细节可能导致问题。最后，故事划分过于频繁可能会使得工作量难以管理，因此需要谨慎划分故事，以确保项目的可控性。
客户很难为故事安排优先级是最后一个问题，当故事太大或者无法展现商业价值时，就会出现这个难题。作者建议在故事的编写中尽量保持商业价值的明确性，以便更容易为故事安排优先级。
