需求收集与文档记录的新方法
1. 客户特定代码请求处理
在处理客户特定（且付费）的代码请求时，需要遵循一定的原则。以下是处理此类请求的一些注意事项：
| 应该做的 | 不应该做的 |
| — | — |
| 承诺实现功能 | 在未涉及账户管理团队的情况下调整范围 |
| 以用户故事格式记录需求 | 在现有资源和条件下承诺一个“乐观”的日期，确保日期合理可实现 |
| 透明地展示一系列冲刺中的开发进度 | 同意性质模糊或容易被误解的用户故事或需求 |
| 考虑邀请客户参加冲刺演示/评审 | |
虽然客户特定代码请求的某些方面可能不适合敏捷框架，但通过与客户进行协作和透明沟通，可以有效地管理这些事情。
2. 沟通的重要性
拥有可靠的需求和清晰的行动计划只是需求工作的一部分。有效的敏捷实施强调透明度，这意味着内部和外部的关键利益相关者都要充分了解正在进行的活动及其对组织的影响。
3. 共享愿景
在敏捷开发中，确保团队、产品负责人、利益相关者以及其他相关角色理解产品愿景和发布内容非常重要。这通常是产品负责人的工作，对于复杂或大型项目尤其有帮助。
一个很好的例子是Cayman Design正在开发一款新产品，预计需要进行多个冲刺，可能长达六个月才能首次发布。在产品最终成型之前，有大量代码需要编写，也有许多决策需要做出。团队可能想立即开始编写代码，但花时间共享愿景有助于设定合理预期，避免后期返工。
例如，报告功能通常是产品发布最后才考虑的事情，因为它在产品进入市场、被选择、订购、交付和使用之后才会发挥作用。然而，关于存储哪些数
