借助飞书多维表格实现敏捷管理(Scrum)

Category: work Tags: Scrum Management

前言

入职了新公司，由于在项目流转体系上不够规范，于是想着去推行Scrum，公司是用飞书进行沟通的，就想能否最大化的利用现成的工具，将理念及流程建立起来。

过程

之前用得比较多且顺手的是confluence+jira，但jira对当前公司来说可能得找个破解的，并且目前jira已经逐渐不再维护部署版，推荐cloud版，cloud版的收费不太便宜；

也看过一些其他的，pincode，ones，tower，teambition，worktile等，收费策略基本上是两类，不是人数，就是ticket数进行收费，对于初创公司3，50人来说左右比较尴尬，每一笔投入都需要考虑。于是都放弃了，最后转回飞书系，飞书本身其实也有项目管理的功能，但是一聊发现也是有门槛的，如下：

最关注的表格数据容量限制：

基础版	商业版			企业版
免费	标准	专业	旗舰	标准	专业	旗舰
2,000 行	2,000 行	20,000 行	50,000 行	50,000 行	50,000 行	50,000 行

以现在的规模用个一年不是问题，实在到了可以数据备份或者开新表格，

最后决定基于多维表格先形成自己的规范。

PS：个人最近比较喜欢新出的Linear，国外的产品，免费版限制250个ticket。

执行

Scrum介绍

这里不做敏捷的专题，但还是引用下来自Wiki的简单介绍

Scrum is an agile team collaboration framework commonly used in software development and other industries. Scrum prescribes for teams to break work into goals to be completed within time-boxed iterations, called sprints. Each sprint is no longer than one month and commonly lasts two weeks. The scrum team assesses progress in time-boxed, stand-up meetings of up to 15 minutes, called daily scrums. At the end of the sprint, the team holds two further meetings: one sprint review to demonstrate the work for stakeholders and solicit feedback, and one internal sprint retrospective. A person in charge of a scrum team is typically called a scrum master.

Scrum是用于开发、交付和维持错综复杂产品 (complex products) 的敏捷框架 (framework) [1] 。最初着重于软件开发，之后已被用应用于其他领域，包括研究、销售、营销和其他先进技术领域。 一个 Scrum 团队建议为十名成员的团队而设计的，他们以迭代[2] （iterative）与增量[3] （incremental）式的方式交付工作，每个迭代称作 Sprint。一个 Sprint 的时间不超过一个月，通常是两星期。Scrum 团队在每个 Sprint 都专注在唯一一个共同的目标 （Sprint Goal），每天会有称为Daily Scrum的站会，团队中的开发人员（Developers）会检视朝向共同目标的进度，和调适当下的计划。在 Sprint 结束时，团队会进行 Sprint 审查 (Sprint Review) 跟利害关系人 (Stakeholders) 一起检视当下的结果与调适计划，这是互相资讯交流的机会。最后，团队会进行 Sprint 回顾（Sprint Retrospective）来持续改善。

多维表格

六张数据表+一个仪表盘 仪表盘：顾名思义，根据维度组合成自己想要的展示，这里我的示例：

六张数据表：

1. Sprint（冲刺）

   • Current Sprint Board（看板视图）
   • Backlog By PM（表格视图）
   • Backlog By Dev（表格视图）
   • Sprint Planning（表格视图）

2. Sprint Bug（冲刺内部Bug）

   • Current Sprint Bugs（表格视图）

3. Release Version（发布版本）

   • 发布版本计划（表格视图）
   • 发布日历（日历视图）

4. Sprint Version（冲刺版本）

   • 迭代版本计划（表格视图）

5. Epic（项目里程碑）

   • 项目管理（表格视图）
   • 项目计划（甘特视图）

6. CFD（客户反馈缺陷）

   • 反馈表（表格视图）

PS：根据公司规模和习惯，可以将其他部门的内容纳入进来，比如这边产品想自己再维护一个自己的产品需求池，那也没关系，关联进story/task即可。 最终形态参考：

缺点：

1. 权限控制
2. 触发更新
3. 配合scrum的燃尽图之类的不支持
4. 子任务不利于总体story估时

最后

给一些过程中的约定参考 说下关于产研团队协作大致的规划： 所有任务到Board上管理，Current Sprint Board拖动状态展示进度 整个工作按以下顺序推进，当前处在一阶段

准备阶段

1. 产品将会管理好自身的需求池（位置：Scurm-产品需求池）

2. 每周定期一到两次和产品梳理需求（Grooming阶段）, Grooming阶段目的是澄清需求、理清依赖、框定范围（DoD：完成定义，AC：验收标准）、达成共识

3. 进一步将需求池中的需求拆解到Sprint，统一说法叫拆解为Story，产品维护PM Backlog（有一定的标准，目前需要磨合），开发维护Dev Backlog

​ 原则上：

• 一个Story完成时间不宜过长，一般1-6天比较合适

  • 可以按照模块来拆分，比如商家中心，支付中心，系统设置等，根据模块内内容可以再细分
  • 产品提前规划好模块间的依赖，以便评审的时候有顺序连贯性

• 模块如果有第三方依赖，或者现成产品/功能/数据直接对接的，在文档中注明，产品需要提前调研

• 评审主要针对产品功能，对于技术方案不引申扩展，研发部线下决定是否再拉起会议变更
• 产品将内容分享至飞书，以模块或者功能（对于周期较长的项目）来构建页面，一切变更在飞书页面留下记录，开发测试都可做评论提问回答

• 评审内容以及会议不宜过长，建议一个小时内，最长一个半小时，分阶段进行以便消化（隔天隔周），紧急任务休息10-15分钟继续

• 开发测试针对拆解的Story进行时间评估（资深或架构师参与）

• 和产品对齐当前Sprint需要完成的Story

启动阶段

1. 任务启动，第一天开始前开发和产品测试对齐（我们主要和依赖方以及测试），确定好任务开始的时间

进行阶段

1. 不允许接“私活”（1-2小时就能解决的，自由处理），前提且务必重要的一点是：不能影响主线！
2. 如果有临时任务插入，包括技术和外部新需求，或者紧急Bug，1天以上的，及时汇报调整优先级，会在Board上记录跟踪
3. 需求变更导致的影响范围大于当初评估的时间，及时提出风险

结束阶段

1. 如有必要，任务评论下写上完成结果记录，包括变更事项，完成范围，原因等（内容合理即可）

其他：

1. 启动会，每日站会，回顾会视磨合以及实际执行情况逐情介入

版权声明：自由转载-非商用-非衍生-保持署名

Go Top