客户协作
响应变化
-
正确看待变化，变化得发生可能源于：
- 用户和市场的变化
- 新的反馈
- 人的认知局限性，不可能完全准确的描述未来较长时间所需要的需求细节
-
我们真正的目的是创造成功的产品/应用，而不是完成项目交付！变化意味着机会！
-
敏捷没有传统的需求变更流程，建立轻量级的机制来响应变化；
- 基于动态优先级顺序的交付
- 短迭代周期，延迟承诺
VS胜过遵循计划
-
敏捷不是没有计划，而是不相信大计划，要做小计划（2周迭代计划），经常做计划；
-
持续做好产品规划，明确产品发展方向，也有利于保持均衡的需求量；
-
在每一个短的迭代计划中，尽力保持需求的稳定不变；
-
每个迭代计划越短，团队快速响应变化的能力越强；
敏捷宣言
敏捷宣言的12条原则
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使开发后期也一样。为了客户的竞争优势，以灵活的过程掌握变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务、产品与开发人员必须相互合作，项目中的每一天都不例外；
- 激发个体的斗志，以他们为核心搭建团队。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈；
- 可工作、有价值的软件是进度的首要度量标准。
- 倡导可持续的开发节奏。团队责任人、开发人员和需求人员要能够共同维持其步调稳定延续；
- 坚持不懈地追求技术卓越和良好涉及，敏捷能力由此增强；
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和涉及出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的行为表现，持续改善。
经常用敏捷宣言的12条原则来审视：我们是否真的敏捷？
敏捷不是一套流程，敏捷是管理原则，和一套创造优秀软件的实践！敏捷是开发产品，而非交付项目！
敏捷需要的是纪律和能力，持续改进！
敏捷开发中DM、PO的职责
交付经历DM（我要确保这个团队是卓越的）
- 培养团队成员，引导制定团队契约，形成信任、开发、平等、尊重，学习、协作的团队文化；
- 与DDA合作，主导或推动概要涉及活动及时有效开展，保证概要设计质量；
- 带领跨职能敏捷团队以敏捷方式持续高效运作，制定合理迭代计划，有效组织关键活动，保障交付质量；
- 建立管理层、业务方、PO和团队之间的沟通渠道，消除沟通障碍；
- 与PO合作进行迭代版本规划，协作其管理产品待办清单，尤其是其中的技术故事和债务、预研工作项；
- 透明化地管理团队交付进度、风险和依赖，及时协调解决阻碍；
- 与其他关联团队合作，协调跨团队之间需求、设计和任务排期与集成；
- 收集和分析过程与结果度量数据，推动团队持续改进；
产品经理PO（我要确保这个产品是成功的）
- 与业务、客户和公司相关干系人对齐产品愿景与目标；
- 对用户和客户进行深入研究，理解并定义产品要解决的问题及价值；
- 主导或解决方案团队合作开展产品方案与原型设计，保证需求质量；
- 制定产品的演进路线，滚动进行产品的迭代版本规划；
- 拆分并定义用户故事，书写验收标准，管理产品待办清单，并对清单中故事和其他工作项排优先级；
- 支持团队高效、高质量交付，及时讲解和澄清团队对需求与产品设计的疑问；
- 组织业务验收，或组织团队给业务或用户进行演示，尽早收集反馈；
- 设计关键运营指标，收集和分析数据，验证产品和需求的真实成效，从数据反馈发现用户或业务问题，产生进一步改进想法。
如何成为好的PO？
- 基础能力：领域知识、沟通引导、组织协调
- 基础专业能力：探索研究，产品设计，敏捷需求
- 进阶专业能力：业务规划，产品运营
阅读更多[敏捷知识]、[敏捷转型经验]、实践等…欢迎关注掘金账号@鲸舟研发管理
如果对我们的产品感兴趣，可以逛逛我们的官方网站鲸舟研发管理平台 试用了解
