敏捷ACP
敏捷思维
6点价值驱动要素
- 着眼未来、活在当下
- 精益思想、快速验证
- 懂得取舍、需求差异
- 转变思维、三角倒置
- 尽早交付、及时反馈
- 价值驱动、有限排序（PBIs）
敏捷宣言
4个价值观
- 个体和交互 > 流程和工具
- 可工作的软件 > 面面俱到的文档
- 客户合作 > 合同谈判
- 响应变化 > 遵循计划
12条原则
- 1、我们的最高目标是，经早持续交付有价值的软件来满足客户的需求
- 2、欢迎对需求提出变更，即使在项目开发后期也不例外。善于利用需求变更帮助客户获得竞争优势
- 3、经常交付可用的软件，周期几周～几个月不等，越短越好
- 4、善于激励项目人员，给予他们所需要的环境和支持，并相信他们能完成任务
- 5、信息传达最有效的方式是面对面的交谈
- 6、可用的软件是衡量进度的首要衡量标准
- 7、敏捷过程提倡可持续发展的开发
- 8、对技术的精益求精、设计的不断完善将提高敏捷性
- 9、简洁，尽最大可能的减少不必要的工作
- 10、最佳的架构、需求、设计将出自于自组织的团队
- 11、团队要定期反省怎么做才能更有效，并相应的调整团队行为
- 12、项目过程中，业务人员和开发人员必须始终通力合作
敏捷流程+原则
3345流程
-
3-Roles(角色)
- Product Owner（产品负责人）
- Scrum Master（团队负责人）
- Dev-Team （开发团队）
-
3-Artifacts（产品）
- Product Blocklog（产品功能列表）
- Sprint Backlog（冲刺列表）
- Burn-Down Chart（燃尽图）
-
4-Ceremonies（会议）
- Sprint Planning Meetting（迭代计划会议）
- Baily Scrum Meetting(每日站立会)
- Sprint Beview Meetting（迭代评审会议）
- Sprint Retrospective Meetting（迭代回顾会议）
-
5-Value（价值）
-
开放
- 信息开放、态度开放
-
勇气
- 迎接质疑、勇于说“不”、准备突破现状
-
尊重
- 推崇开放、遵守工作规范、鼓励积极的工作状态
-
专注
- 平衡工作专注的时间与团队成员交流的时间、把时间都放在冲刺目标上
-
承诺
- 团队对结果负责、必须保证每次冲刺目标都是有价值的
-
敏捷项目阶段
1、立项
2、启动
3、发布计划
-
4、迭代
- 迭代计划
- 开发及测试
- 每日站立会
- 产品发布
- 评审会议
- 回顾会议
- Blocklog梳理
-
5、收尾
- 1、项目回顾会议
- 2、总结经验教训
- 3、成果交接
- 4、文档归档
敏捷角色及职责
-
Product Owner（产品负责人）
-
职责
- 清晰的表达产品代办列表项
- 决定发布日期和发布内容
- 为产品ROI负责
- 根据市场价值确定功能优先级
- 确保产品待办列表对所有人是可见、透明、清晰的
- 接受/拒绝接受开发团队的工作成果
- 维护产品Blocklog,对工作优先级排序，是PBIs列表的唯一负责人
- 确保研发团队对产品待办列表项有足够深的了解
-
优秀的PO特征
-
善于沟通
- 和干系人关系好
- 促成谈判/达成一致意见
- 良好的沟通能力
- 正能量
-
责任心
- 承担产品责任
- 参与并随时可用到场
- 充当Scrum团队成员
-
懂业务
- 有预见性
- 知道哪些事情是无法遇见的
- 具备业务和领域专长
-
决策力
- 可用制定决策
- 关键时刻敢拍板
- 有决断力
- 从经济的角度权衡业务/技术问题
-
-
-
Scrum Master（敏捷教练）
-
职责
-
帮助
- 帮助创建信息辐射器
- 协助团队向管理层汇报
- 帮助团队回顾并持续改进流程
- 帮助团队维护自己的Scrum工具
- 作为变革的催化剂帮助团队监控指标
-
奖励
- 为完成或者交付的好工作而自豪
- 庆祝难忘的成果时刻
-
学习与分享
- 不断的学习关于敏捷的一切
- 关于团队敏捷教练和咨询
- 不断与其他SM互动交流经验
- 定期给团队反馈
-
促进
- 各类型的会议和Scrum仪式
- 所有干系人与团队的合作
- 团队的发布计划
- 创造合适的DOD
- 保持可持续的步调
- 团建活动
-
鼓励
- 面对面交流
- 团队自组织与责任
- 会议的透明、开放
- 适应性改变
- 合作解决问题
-
保护
- 翰旋冲突
- 帮助团队摆脱障碍
- 保护团队免受外界的障碍
-
-
日常工作内容
组织推进Scrum活动
-
指导团队成员
- 使用Agile(敏捷的)流程
- Agile(敏捷的)相关工具的使用
和PO(产品负责人)梳理PBI（产品待办事项）
清扫障碍
-
能力要求
- 促进合作
- 激励团队
- 沟通决策
- 冲突管理
- 抗压
- 敏捷实践
-
-
Scrum Team（敏捷团队）
团队是指一些技能互补、有着共同目标和愿景、共同承担责任的人
- 组件团队
- 优点
- 按照系统架构模块，或者分层组织团队
- 每个团队只专注于他们负责的组建模块
- 弊端
- 不利于跨组件或者各个层之间的沟通
- 跨团队的协调和依赖管理更加复杂
- 由于各个层次需求量的不同，很容易产生等待
- 由于职责单一，限制学习，是的专业更加单一化
- 容易产生低价值的交付
- 延迟价值交付
- 特性团队
- 优点
- 长期稳定的团队，逐个端到端完成客户特性
- 跨职能、完整团队
- 共享代码库、统一的持续集成
- 拥有通用型专家
- 弊端
- 团队可用做到端对端，减少等待实，周期加快
- 比较容易在一个sprint中交付可用的产品增量
- 减少团队之间的依赖，计划会更容易
- 责任范围的扩大，各种不同领域的专家在一个团队，增加个人学习和团队学习的机会
- 开发团队标准
- 特点
- 自组织、透明沟通、5～9人、跨职能、多样化、成员稳定、T型技能、集体责任、相互承若
- 要点
- 团队绝对要做什么（任务自领）
- 团队决定如何做（团队做技术决策）
- 在确保目标的前提下，团队自己制定行为准则
- 管理层和SM通过引导的管理的方式给出指导思路
- 管理层不能决定团队内的工作分配
- 职责
- 定义（分解）工作任务
- 评估工作量，开发产品
- 确保质量，完成过程
- 定义DoD（Definition of Done“完成的定义”）
- 关于团队效率
- 当团队不受干扰的时候效率最高
- 团队在自己解决问题后，成长更快
- 跨职能完整团队的效率更高
- 团队的稳定性是影响团队效率的重要因素
- 相对于别人为自己许下的承若，大家应该更加重视自己的承若
- 迫于压力下的“努力”工作，开发人员总是会“自觉地”降低工作质量，而且质量会越来越低
- 团队发展5个阶段
- （指导式-形成）团队组建-》设定团队规则-》设定每个人职责
- （教练式-震荡）团队磨合-》冲突和质疑-》挫败和反思
- （支持式-规范）默契形成-》规则沉淀-》节奏感与配合
- （授权式-成熟）效率提示-》自我优化能力
- （命令式-解散）团队解散
- 如何打造自组织团队
- 从控制团队 转变 自组织团队
- 自组织团队有权进行设计、计划和执行任务
- 自组织团队自己监督和管理项目过程和进度
- 自组织团队自己决定团队内如何开展工作
- 敏捷团队沟通管理
- 渗透式沟通
- 分布式团队
- 工作协议要点
- Who：谁来定工作协议
- 团队自己
- SM或者团队管理者提供指引技术
- 自己选择的路，跪着也要走完
- When：什时候制定工作协议
- 敏捷团队开始的时候
- 持续优化
- How：怎么制定工作协议
- 工具：白板、马克笔、便利贴
- 步骤
- 开场：SM跟团队解释工作协议是什么
- 发散：静默式头脑风暴，写在便利贴上面
- 收敛：SM收集便利贴，放到白板上面，每个人介绍自己的工作提议，团队投票
- 承若：投票的结果是否有异议，达成一致意见
- 可视化：放大内容，张贴在白板上或者工作区域内
- 工作协议范例
- 每天下班前提交代码
- 如遇到决策不统一，少数服从多数原则
- 每天9点30开晨会，迟到发红包10元/5个
- 对事不对人，不做人身攻击
- 所有Doing（正在做的）工作项要符合DoD（完成的定义）才能Done（做）
- 每天下午14:30～17:00为团队免干扰期，除非特别重要的事情
