敏捷项目管理(技术产品)落地实践
Part A: All-in-One 智能化研发管理工具
PingCode 产品怎么样？产品底层逻辑是什么样的？ - 易成管理学 - 博客园 (cnblogs.com)
*零、起点 Goals + Insight
Goals（目标管理）：提供战略目标、团队目标、个人目标管理，让所有项目都聚焦于共同的目标，并在更高视野上及时了解企业目标进展；
Insight（效能度量）：提供研发效能自动采集等能力，通过数据驱动的方式更加准确地评估和改善研发效能；
一、产品管理组 Ship
【需求/Bug收集、需求管理、产品路线图】Ship
Ship（产品管理）：提供工单收集、需求池管理、需求评审、产品路线图等能力，打通客户、业务团队和产研团队之间的协作，帮助团队规划产品路线；
二、技术开发组
【团队文档管理】Wiki
Wiki（团队知识库）：提供文档协作、结构化团队知识管理等能力，帮助生产和结构化沉淀团队规范、制度、实践经验；
三、项目管理组 Project
【敏捷项目、kanban项目、瀑布开发项目管理、项目集】Project
Project（项目管理）：支持敏捷开发、瀑布开发、Kanban等国内主流研发管理模式，以及规模化敏捷（SAFe）、项目集等的管理，规范团队的协作流程；
四、产品测试组 Testhub
【测试用例、测试计划、测试报告】Testhub
Testhub（测试管理）：提供用例维护、评审，测试计划、自动化测试、测试报告、缺陷提交等能力；
五、质量监督组 Insight
【源码管理】、【部署管理，持续集成】第三方插件形式搞定
六、服务支持
Flow（研发自动化管理）：提供自动化技术，将重复性和烦闷的手动操作变成自动化执行，让团队专注高价值生产；
应用市场：集成了研发中主流的软件，如Git、Jenkins、gitlab等等，实现了不同软件间的数据打通；能够在飞书、企微等平台使用；
Part B: Scrum 敏捷项目管理框架
- 需求管理：史诗/特性/用户故事三级体系，根据优先级、故事点形成待办列表
- 产品规划：根据产品目标及项目需求排期，规划产品路线图、迭代和版本
- 迭代管理：将需求和Bug分配到迭代，通过燃尽图、速率图等跟踪迭代进度
- 版本管理：支持多版本共存，新增功能和修复对应版本
- 开发管理：拆分用户故事为任务，开发人员领取任务完成 Coding
- 构建部署：工作项关联代码托管、CI/CD 工具，跟踪开发、构建及部署进度
- 工时统计：估算、填报任务工时，可视化度量项目和团队工作量
一、敏捷宣言可以总结为四句话：
个体与交互 优于 流程与工具
客户协作 优于 合同谈判
响应变化 优于 遵循计划
可工作的软件 优于 面面俱到的文档
也就是说，尽管右项有其价值，我们更重视左项的价值。
不管你走了多远，错了就要重新返回。
二、敏捷的宗旨是减少浪费
所有的敏捷实践也都是围绕着高效协作与快速反馈这两个核心理念展开。
在一个高度协作的环境下，不断的通过反馈来进行自我调整和完善。
● 协作：体现在团队与客户之间的协作，团队成员之间的协作。
● 反馈：包括开发中的任何环节，如代码质量、自动化测试、部署、项目进度、需求变更、客户验收等，而且反馈越快越好。
三、敏捷实践主要围绕迭代进行
用一张图概括：
过程中的关键点：
● Iteration通常始于IPM（Iteration Plan Meeting，迭代计划会），止于Showcase（演示用例/功能）。
● Daily 每天都会发生事件有 Standup （每日站立会）。
● Pair（结对编程）、TDD（测试驱动开发）、Code Review（检查代码）穿插在日常Coding中。
● Story kick-off（开卡:启动一个Story）之后，该 Story 就进入了开发环节；每个Story写好之后，Dev在座位上让BA、QA做Card Sign off(结卡/产品签收), 俗称 Desk check。
● CI（持续集成）属于基础设施，通常在一个名为 Iteration-0 的迭代完成，也就是正是开发开始之前就应该完成 CI 的搭建。
● Retro（回顾/复盘会）较长一段时间才进行的活动，根据实际情况，1个月或两个月举行一次。
● Regular catch up with client（定期与客户进行沟通）也会因项目而异，Daily 或者 Weekly，甚至某些项目可以省略该项活动。
三、敏捷管理工件
主要指三大核心工件：产品待办事项清单 PBL（产品待办事项，Product Backlog Item）、迭代待办事项清单 SBL（迭代待办事项，Sprint Backlog Item）、产品增量 Increment。
| 责任人 | 评审会议 | 工件 | |
| 产品负责人(PO) | 产品梳理会(Product Backlog Grooming Meeting) | 产品待办清单PBL | 产品愿景 Product Vision |
| 敏捷教练(SM) | 迭代计划会(Sprint Planning Meeting) | 迭代待办清单SBL | |
| 质量保证(QA) | CI/CD | 产品增量Increment |
Epic、Feature、Story和Task用来划分需求颗粒度的标签：
Epic 史诗: 是公司重要战略举措；基于产品的长期战略方向而被提出，需求级别最大，通常为可独立使用的一个产品模块，通常是一些特性的集合，在项目进度中被设置为“里程碑”。
Feature特性: 是对你的用户有价值的功能；作为比史诗更具体的子需求和若干个用户故事的集合，承上启下。
Story用户故事: 是分解的细粒度的开发交付的内容，是用户的细分场景；是从用户的角度编写的简短需求或请求，能在一个迭代中开发完成。
Task任务: 是完成需求的过程性的工作。
这些术语和概念，来自于业界的共识，对于软件企业，是实现从战略举措到战术执行落地的分层设计
Definition of ready (DoR)
DoR 给出了当前已具备的各种条件是否具备了真正开始某个用户故事的标准。
Definition of done (DoD)
DoD 给出了是否真正完成的标准。在许多情况下，DoD 要求所有的回归测试都要完成。“完成” 的定义可能因 scrum 团队的不同而不同，但必须在一个团队内保持一致。
3.1 产品待办清单(Product Backlog List)
产品待办列表 是一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的 唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。
产品待办列表列出所有的特性（Feature）、功能（Function）、需求（Requirement）、增强（Enhancement）和修复（Fix）等对未来要发布的产品进行的改变。
产品待办列表项：https://www.jianshu.com/p/6ba0034d1a51具有这些属性: 描述、次序、估算和价值。 产品待办列表项通常包括 测试描述，将在“完成”时证明其完整性。
产品待办列表中可能有不止功能性需求（Function），还有非功能性特性（Feature）。比如：缺陷(Bug)修复、基础技术任务（Task）、比较大的用户故事(User Story)即史诗(Epic)、代码改进、架构优化、功能优化等等。
注意：用户故事是从用户的角度讲述他或她想要什么，而不是系统能为他做什么。因此，观点完全从产品转变为用户，用户故事成为所有敏捷框架中需求的事实上的标准。
| 场景 | 格式 |
|
用户故事是根据定义的格式来叙述的： |
As (persona), I want to (expression of the wish), so that (goal to achieve). |
| Chris Matts 认为"寻找价值"是成功交付软件的第一步，并提出了这一替代方案： | In order to <receive benefit> as a <role>, I can <goal/desire> |
| 还有另一种基于 5W 的模板： | As <who> <when> <where>, I <want> because <why> |
参考：https://blog.csdn.net/tool007/article/details/144388140
| 编号 | 标题 | 描述 | 来源 | 优先级(重要/紧急) | $APPEALS | 卡诺KANO模型（BSA模型） | 通用等级(MoSCoW模型) | 商业价值 | 工作量评估 | 实现难度 | 版本规划 | 负责人 | 状态Status | 备注(DOD/问题/变更) |
| UR- | APP端用户登录模块，...... | 场景/分类 | 记录需求来源，包括：客户需求、内部需求、市场需求等 | 1~5级，5最高 | 价格（$ Price）、可获得性（Availability）、包装（Packaging）、性能（Performance）、易用性（Ease of use）、保证（Assurances）、生命周期成本（Life cycle costs）、社会接受程度（Social acceptance） | 需求分析维度；预置： B（basic）：基本需求（核心业务功能和特性） S（satisfied）：满意度需求（增值或附加业务） A（attractive）：兴奋型需求（少数特定场景的需求） |
摩斯科(MoSCoW)优先级划分，它按照四个优先级划分需求：必须具备（M-Must have）、应该具备（S-Should have）、可以具备（C-Could have）、不会具备（W-Won’t have）｛暂缓(won’t have this time,WHT)、不必(won’t have ever,WHE)｝。 |
1~5分 | 设计; 开发; 测试; |
1~5级，5最高 | 设计; 开发; 测试; |
设计 开发 功能、性能、可靠性验证 |
||
| PR- | ||||||||||||||
| SR- |
用户故事条目的关键属性(编号、标题、描述、状态、优先级、工作量大小、团队、发布版本/迭代、完成条款DOD)
- 负责人， 当前需求的负责人
- 分类， 必填；默认值[常规需求]，分类决定当前需求单据属性显示及状态；
- 来源 ，记录需求来源，包括：客户需求、内部需求、市场需求等
- 来源说明， 需求来源的补充说明；特别需求来源选择[其它]时，需要补充来源说明
- 优先级， 描述当前需求的优先级；下拉选项：高、较高、中、较低、低
- BSA， 需求分析维度；预置： Basic、Satisfy、Attractive
- 通用等级， MoS需求分析维度；必须(M-Must )、应有(S-Should have)、可有(C-Could have)、暂缓(won’t have this time,WHT)、不必(won’t have ever,WHE)
- 时间维度， 需求划分维度；通用需求、长期需求、中期需求、短期需求、定制需求、紧急需求、已上市产品需求
- 关联项目， 当前需求明确直接通过项目实现时，可与项目进行关联；
- 状态(status)字段，总共有四种状态，分别是草稿(draft)、激活(active)、已变更(changed)和已关闭(closed)。对应为需求的流程操作共有：创建、变更、审核、关闭、激活，
- 阶段(stage)字段，用来描述激活的需求在研发过程中所处的阶段： 需求研发阶段：目前总共有未开始、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。
- 期望实现时间， 需求提出人针对当前需求的期望实现时间；
- 预计交付时间， 需求处理人针对当前需求的预计实现时间；
- 产品设计负责人， US用户故事中，直接分配产品设计负责人；
- 开发负责人，US用户故事中，直接分配软件开发负责人；
- 测试负责人，US用户故事中，直接分配测试负责人；
- 设计工作量，US用户故事中，标记评估的产品设计工作量；
- 开发工作量，US用户故事中，标记评估的软件开发工作量；
- 测试工作量，US用户故事中，标记评估的应用测试工作量；
下文数量，记录当前层级需求的直接下文数量；
关键特性，SF系统特性专属标识；
MoSCoW模型 必须有(must)、应该有(should have)、可以有(could have)、暂缓(won’t have this time,WHT)、不必(won’t have ever,WHE) "Must"（必须有）、"Should"（应该有）、"Could"（可以有）和"Won't"（不会有）四个级
参考:https://vip.kingdee.com/knowledge/606061008418857728?productLineId=40&isKnowledge=2&lang=zh-CN
KANO模型
根据KANO模型建立产品需求分析优先级，运用到产品设计中就是要抓住用户的核心需求，解决用户痛点（基本（必备）型需求），
抓住用户痒点（期望（意愿）型需求）。在确保这两者都解决的前提下，再给用户一些high爽点（兴奋（魅力）型需求），
在这当中，避免触碰到无差异型需求及反向型需求
BSA模型
基本需求（Basic）、最好满足的需求（Attractive）、更具有吸引力的需求（Attractive）
3.2 迭代待办清单(Sprint Backlog List)
迭代计划会：
输入：PBI(Story、AC、DoD)
输出：SBI( Task )
| 任务编号 | 任务名称 | 任务类型 | 任务描述 | 优先级(重要/紧急) | 当前状态 | 负责人 | 预估时间(开始/截止日期) | 完成情况 | 备注(问题/变更) |
| R- | AI技术可行性 | 调研(需求/技术) | 高 | 未开始 | 16 hour | 0 | |||
| D- | 设计UI界面更新 | 方案设计(UI/数据/架构/安全) | 中 | 进行中 | 16 hour(20251001-1003) | 50% | |||
| D- | 实现用户权限管理 | 编码 | 一般 | 完成 | 16 hour | 100% | |||
| T- | 测试用户登录功能 | 测试(自动/手动,功能性能安全) | 低 | 暂停 | 16 hour | 20% | |||
| F- | 修复已知的Bug#123 | 缺陷修复 | 16 hour | ||||||
| p- | 优化数据库查询效率 | 优化重构(可维护性、性能、用户体验) |
任务名称:
任务描述：简洁明了地说明任务目标。
任务类型: 调研(需求/技术)、方案设计(UI/数据/架构/安全)、编码、测试(自动/手动,功能性能安全)、缺陷修复、优化重构(可维护性、 性能 和用户体验)
优先级： 指示任务的紧急程度。高、中、一般、低
当前状态：任务在看板上的当前位置，反映其进度。未完成、进行中、已完成和暂停。更细化一些，采用如下描述，
- 1. 待办 (To Do)
- 2. 进行中 (In Progress)
- 3. 挂起 (On Hold)
- 4. 等待审查 (Pending Review)
- 5. 需要信息 (Waiting for Information)
- 6. 阻塞 (Blocked)
- 7. 延期 (Deferred)
- 8. 已完成 (Completed)
- 9. 已取消 (Cancelled)
- 11. 已验证 (Verified)
- 12. 可部署 (Ready for Deployment)
- 13. 已部署 (Deployed)
- 14. 已交付 (Delivered)
- 15. 已关闭 (Closed)
- 16. 重新打开 (Reopened)
- 17. 代码审查中 (Code Review)
- 18. 测试中 (Testing)
- 19. 回归测试 (Regression Testing)
负责人： 负责执行任务的团队成员。
预估时间(开始/截止日期)：预计完成任务所需的时间。
完成情况：百分比
依赖关系：
备注：备注可以记录任何与任务相关的重要信息、特殊要求或注意事项。如问题或变更等。
看板：
Sprint Backlog通常以看板Kanban/任务板(墙)的形式展示，看起来如下图所示：
每一行代表一个Prouct backlog项也可以称作一个用户故事.
在Sprint计划会议期间，Scrum团队会分解每个用户故事得到许多的Sprint backlog项，每一项作为一个任务卡放到任务墙上。
常用的 列 如下：
- Story-用户故事。根据产品需求分解出的一个个用户故事.
- To Do–待办。需要完成的，但还未开始的任务。
- Doing–进行中。，或刚刚开始的任务。
- To Verify-待测。
- Done–完成。所有已经完成的任务卡都会放在这里，Sprint结束的时候可以拿掉它们。
每个任务卡从To Do这一列开始。通常包括技术调研、设计开发、测试验证、问题缺陷修改、重构等任务。
3.3 潜在可交付的产品增量(PSPI)
四、敏捷管理工具--看板
敏捷看板：https://www.informat.cn/qa/175459
管理工具的基本要素包括，看板（Board）、卡片（Task Card）、进度列（Task List）, 其中里程碑（Milestone）通常不在看板中表现。
3.1 看板（Board）
卡片 (故事卡、管理卡、技术卡、缺陷卡)，是最小任务单元。
项目管理工具卡片主要有: 任务卡片、进度卡片、资源卡片、时间卡片、风险卡片。
Jira 支持 Scrum、Kanban 等敏捷方法，是一个强大的看板工具，能够帮助团队管理复杂的开发流程和项目
包括缺陷跟踪、需求分析、开发任务等，非常适合技术团队。
附件 A 角色说明：
ThoughtWorks提供完整的交付团队(PM* 1, BA *1 , TL * 1, QA * 1, DEV * 4, UX * 1)，团队为颇具代表性的敏捷团队，规模10人左右。客户团队主要接口人3位。
一、角色：
PO(Product Owner)、BA(Business Analys) 、TL(Technique Leader) 、QA (Quality Analyst) 、DEV 、UX(User Experience)。
Scrum 框架的成功实施离不开三个关键角色的协同配合：产品负责人（Product Owner）、开发团队（Development Team）和 Scrum Master。
这三个角色各司其职又相互依存，共同构成了Scrum团队的核心架构。
1 管理岗(价值 成本 质量)
PM: Project Manager (项目经理) 、 Product Manager | Product Marketing(产品经理)
2 产品需求岗(需求岗)
PO: Product Owner （产品负责人），他们负责确定产品的功能需求和优先级。
BA: Business Analyst（业务分析师）
UER：User Experience Research(用户调研人员)
3 设计开发(技术岗)
SM: Scrum Master （敏捷教练/Scrum教练）流程管理员
TL: Technical Leader（技术领导）
UX：User Experience (用户体验设计师) 关注用户在使用产品或服务时的整体感受和体验,包括易用性、可靠性、满意度、愉悦度、吸引力等
PD: ProductDesigner (产品设计师)
UED: User Experience Design (用户交互设计师) | UI: User Interface (用户界面设计师)
Dev: Developers（开发人员），他们是团队中的核心力量，负责编写代码、实现功能。
4 测试岗(技术岗)
QA: Quality Analyst | Quality Assurance 测试工程师(质量分析/保证工程师)
5 运维与技术（支持岗）
TS: Technology Support (技术支持)
DevOps: (Operation运维开发工程师)
二、敏捷开发的流程：
IPM（迭代计划会）
参与人员：所有人
BA阐述新迭代新迭代的计划和目标，讲解新的需求卡片
TL DEV估故事点（人力分配）
QA 了解业务需求，构思测试点
Story kick off（开卡）
参与人员：BA QA UX DEV
BA：根据分配给开发人员的卡片进行解读，使参与者对需求的理解达成一致
QA：提出需求设计存在不合理的地方，或者补充更加详细的需求细节（功能点）
UX：与开发人员对用户体验上的前端页面细节做确认
结卡
参与人员：BA QA UX DEV
验收开发人员开发的功能点
每日站会
参与人员：所有人
昨天做了什么，遇到什么问题，今天的计划
Retro（迭代回归会）
参与人员：所有人
1.总结本迭代做的好的，做的不好的，
2.对上次回顾会中总结出做的不好的点在本迭代中是否仍然存在。
3.所有人提出目前仍然存在的问题，并问题讨论出可行的措施，分配任务
4.QA作bug分析的总结
QA工作：
1.参与以上每一个环节
2.迭代开始前期对上个迭代的BUG进行总结和分析
3.站会时提出当前开发进度是否影响迭代的封版，需要BA、TL对开发人员的工作进行重新安排
4.卡片上写 testcases
5.故事卡的测试
6.迭代上线的前三天进行封版
7.回归测试
8.上线测试
附件 B 常用术语
PM：Project Manager，项目经理
BA：Business Analyst，业务分析师
TL：Technical Leader，技术领导
QA：Quality Assurance，测试人员
DEV：Developer，开发人员
UX：User Experience，用户体检设计师
AC：Acceptance Criteria，验收条件
UAT：User Acceptance Test，用户验收测试
Retro：Retrospective，回顾会议
TB: Team building，团队建设
CI：Continuous Integration，持续集成
浙公网安备 33010602011771号