确保敏捷成功 - 成为变革代理人

成为变革代理人

• 组织中实施敏捷的步骤：

  • 第1步：制定实施策略：实施策略是描述组织将如何转型到敏捷项目管理的计划。
    • 自问：
      • 现在的流程： 如何运作，优势，存在的问题
      • 未来的流程：如何收益于敏捷方法，哪些敏捷方法，组织需要哪些改变，团队和流程会变成怎样
      • 循序渐进的计划：如何转型，马上的改变是什么，6个月后的改变，一年甚至更长时间的改变
      • 收益： 敏捷为团队以及组织整体提供什么好处
      • 潜在的挑战： 最艰难的变革是？哪些部门或人员在使用敏捷困难最大？谁的地盘将会收到威胁？潜在的障碍， 如何攻克这些挑战
      • 成功的因素：哪些组织因素会有帮助，对新方法公司应怎样承诺，哪个人或部门担任敏捷推动者
  • 第2步： 建立转型团队
    • 在公司内部确定可以在组织层级负责敏捷转型的团队。由愿意对流程报告需求和绩效评定进行系统性改革的公司高管们组成
    • 转型团队将在冲刺内部创造变革像开发团队创造产品功能一样。将在每个冲刺中专注于高优先级的敏捷变革，并如果有可能在冲刺评审中演示其执行过程
  • 第3步： 构建意识和培养热情：为即将开始的变革凝聚力量，缓解一些因变革而自然产生的恐惧
    • 构建意识的方法
      • 人员教育：敏捷知识库，午餐学习会。。。。。。
      • 使用各种沟通工具：
      • 强调好处：
      • 共享实施计划
      • 初始Scrum团队参与
      • 开放的心态：公开演讲，回答问题，缓解恐惧来积极应对公司内的流言
  • 第4步： 确定一个试点项目
    • 合适的项目特质：
      • 恰当的重要性：重要性足以引起公司的关注，但不是最重要的项目
      • 足够的曝光度：试点项目应该被组织内的核心领导者看到但不要做他们议程列表上的最高调项目以保持自由
      • 明确和可控：有明确需求的产品和可以致力于确定并有限考虑这些需求的业务小组，有着明确结束时间的项目
      • 不要太大：不超过两个Scrum团队同时工作就可完成的项目
      • 切实可衡量的：可在冲刺中展示可度量价值的项目
  • 第5步：确定成功的度量标准：量化的方式度量
    • 衡量项目的评价要素
      • 冲刺目标频率是多少？整个项目实施过程中，冲刺目标的成功率有提高吗
      • 整个项目的实施过程中，冲刺缺陷的数量是否逐步减少
      • 从发现缺陷到修复完成需要多少时间
      • 多久才能把有价值的产品发布到市场上？隔多久能提供一次有价值的升级更新
      • 若产品会带来收入，第一笔钱多久进来，投资的总体回报是多少
      • 与过去传统方法相比，敏捷项目的产品上市时间和投资回报表现如何
      • 客户，干系人快乐吗？项目实施过程中，客户或干系人的满意度是否增加
      • 团队成员的满意度是否增加
      • 其他类型的有价值的衡量指标，项目是否可以演示一些特定的公司目标
    • 衡量员工与绩效的度量指标针对整个团队而不是个人
  • 第6步： 充分培训
    • 与敏捷项目管理专家面对面沟通和通过实践使用敏捷流程的能力相结合，是帮助项目团队吸收和巩固成功运行敏捷项目所需技能的最好方法
    • 项目团队成员（开发团队，产品负责人，Scrum主管，项目干系人）一起训练和学习，培训效果最佳。
  • 第7步：制定产品策略
    • 不要掉入使用传统方法论来编制计划
    • 项目开始时，由产品负责人创建愿景声明来定义产品和总体目标
  • 第8步： 制定产品路线图，产品代办列表和估算
    • 有了定义好的产品策略的愿景声明，开始确定产品特性
    • 产品负责人与业务干系人和scrum团队一起工作，编制产品路线图，产品代办列表和第一个发布计划
    • 产品路线图指出产品的长期方向，但并不需要在启动之前提前确定完成的产品和项目范围。项目开始时，不必为搜集详尽的需求而发愁，后续可随时添加更多需求
    • 开发团队将估算实现产品代办列表的工作量
      *运行第一次冲刺
    • 清晰的敏捷实施策略，积极受过训练的项目团队，有产品代办列表的试点项目和明确的衡量成功的指标， 意味着准备好运行第一次冲刺了
    • 第一个冲刺不要纳入太多需求，一般团队能够完成的工作量比想象的少， 25% 左右，后续增加25% 至100%
    • 不能通过计划排除掉不确定性
    • 第一次冲刺过程，一定要自觉坚持敏捷做法：
      • 每天举行Scrum会议，即使没有取得进展，也需说明存在的障碍
      • 开发团队自管理，除了冲刺代办列表，不要接受来自产品负责人，Scrum主管或任何其他地方分配的任务
      • Scrum主管要记得保护开发团队远离外部工作和干扰
      • 产品负责人要变得习惯直接与开发团队一起工作，随时准备解决问题，审查和验收完成的需求
  • 第10步： 犯错，收集反馈，加以改进
    • 第一次冲刺结束时，冲刺评审和冲刺回顾两个非常重要的会议来收集反馈并加以改进
    • 第一次冲刺评审，对于产品负责人,设定会议形式的预期与冲刺目标和已完成的产品功能一样重要
      • 冲刺评审是做产品演示而非复杂的展示和讲义
    • 第一个冲刺回顾会议也需设置一些预期，特别注意的内容
      • 时刻关注的是满足冲刺目标的程度，而不是完成了多少用户故事
      • 回顾如何完成需求以满完工定义：已创建,已测试，已集成和已归档
      • 讨论距离成功标准的差异
      • 讨论继续推进敏捷流程的进展如何
      • 庆祝成功哪怕一点点收获，同时也要研究问题和寻找解决方法
      • Scrum团队要从团队角度出发举行这个会议，在行动事项上要达到共识，并形成计划。
  • 成熟
    • 通过检查和调整使得团队成长并逐渐成熟
    • 成熟的过程是守破离的过程：
      • 守：遵守敏捷流程的习惯，直到对这些流程变得熟悉
      • 破： 尝试对流程做出改变
      • 离：掌握了敏捷宣言和原则的内在精神，可以自定义适合他们的敏捷流程
  • 推广
    • 完成一个成功的项目是将一个组织转型到敏捷项目管理的重要一步
    • 推广敏捷项目管理理念到整个组织
      • 播种新团队
      • 重新定义衡量指标：整个组织内
      • 有条不紊的推广
      • 识别新的挑战
      • 持续学习

• 避免陷阱

  • 典型的问题以及Scrum团队来纠正这些问题的方法
    
  • 预防性问题
  • 预警的问题：
    • 在做 " Scrum , But …" 吗？组织部分采用敏捷实践的时候就会出现此问题
    • 仍在用老的方式做记录，写报告吗
    • 一个冲刺中完成50个故事点的团队比完成10个故事点的团队更好吗？
      • 故事点只在一个Scrum团队中具有一致性和相关性，而在多个团队之间是不同的
    • 什么时候干系人将在所有的需求说明书上签字？敏捷不需要全部需求都签署才开发
    • 要使用离岸团队来降低成本吗？ Scrum团队应该集中办公，如果是离岸团队，使用优秀的集中办公工具，视频摄像头和虚拟团队工作室
    • 开发团队成员在冲刺中有要求更多的时间来完成任务吗？ 是不是跨职能了，相互帮助了，或者安排了超过开发团队处理能力的工作
    • 开发团队成员会问他们下一步应该做什么吗? 如果等待Scrum主管或者产品负责人的指示，就不是自组织团队。应是开发团队告诉Scrum主管和产品负责人他们下一步做什么
    • 团队成员要准备到冲刺最后才做测试吗：每天测试
    • 干系人会出现在冲刺评审会议中吗？
    • Scrum团队抱怨Scrum主管太过专制吗？ 指挥和控制是自管理的对立面，与敏捷原则直接冲突。Scrum团队成员是平等的， 唯一的老板是团队。
    • Scrum团队正在耗费大量的时间加班吗？ 如果每个冲刺后期都出现急于完成任务的状态，说明并不是采取可持续发展的方式。
    • 回顾什么？回避或取消冲刺回顾，将退回到瀑布方式。即使Scrum团队很好了，还可以更好。