国外机构 Digital.ai 曾在2021年发布《第十五次敏捷状态报告》,报告显示:自疫情发生以来,采用敏捷的软件开发团队有显著增长,从2020年的37%增加到了2021年的84%。除此以外,从敏捷状态调查的早期开始,工具支持一直是决定敏捷成功的关键因素。
Scrum一个是用于开发和维护复杂产品的框架,特别是对于那些有着清晰 Roadmap 的特性开发团队,以便于按照固定的节奏提交价值增量,Scrum更加有完整的套路。
完整的Scrum框架包括:3个角色、3个工件、5个活动和5个价值观:
本文将通过实际测评体验研发管理榜评分最高的敏捷项目管理工具 PingCode 对 Scrum 框架的支持,以及项目管理全过程。(官网地址)
为了让大家更好的理解,我们将按照一个标准Scrum流程为大家介绍说明:
标准Scrum流程
该环节痛点:很多研发团队成员只知道低头做事,完全不知道自己要打造什么样的产品,整个团队无法形成合力;
一个新项目往往是由愿景开始,愿景也可以认为是目标。
虽然敏捷开发凭借其在产品交付速度、质量、风控等方面的显著优势,逐渐在软件开发模式中占据主流,但大量问题仍然阻碍着企业的敏捷实践。其中,研发团队及其所在公司过于看重技术和流程,未能建立“上下同欲”的目标感,就是研发团队经常面临的问题之一。
在 PingCode 有一款专门为目标管理服务的子产品(Goals),它能够帮助项目团队进行目标管理,具体介绍如下:
目标管理同样是很大的话题,详细介绍就不在这里展开。
该环节痛点:很多团队经常面临需求描述、需求优先级及排期问题;
在产品愿景确定之后,团队将进行市场调研等活动,并根据愿景、需求调研逐步构建需求代办列表——需求池管理;
在需求收集和需求管理的过程中,产研团队经常会遭遇两类问题:
而以上问题你都能在 PingCode 找到比较好的解决方案:
过去产品总监没有固定的工具进行产品规划,或者使用Excel,细化调整费时费力,且与研发其他环节的工具割裂;
根据产品代办列表和产品部门的细化,产品愿景的实现路径慢慢清晰起来,并因此形成较为清晰的产品路线图规划。
产品路线图是产品需求在时间轴上的总体视图,它是产品需求与其完成时间的概览,可以使用产品路线图来对需求进行分类、排定优先级,然后确定发布时间表。产品路线图宏观的展示了产品的发展方向以及开发团队何时实现目标。
有效的路线图不仅是一个强调产品发布和功能的时间表:它是一个动态的文档,产品负责人会在项目进行过程中根据实际情况不断更新,所以在创建产品路线图的初期,对需求、工作量、优先级、完成时间的估算不要求也无法很精确,这些内容都是随着项目进行不断细化调整的。
而在过去很多团队都没有专业的工具进行产品规划,或者使用Excel,无论是细化调整还是内部外部的共享都费时费力,且与研发其他环节的工具割裂;
PingCode Ship 是一款专门为产品管理而打造的子产品,使用它能够有效避免以上的问题,比如能够根据你需求的评审排期结果自动生成产品路线图,并选择性同步给需求提出方以及内部团队,反馈需求进度。
除此以外,也不会像Excel那样存在多个版本的问题,而且PingCode 8 个子产品、研发管理各环节都是相互打通。
过去很多敏捷团队可能都面临着开发计划频繁变动,经常有临时任务插队,团队成员的工作状态被频繁打破等问题;
根据路线图,产研团队将需要规划项目/产品版本及发布范围。
然而在很多敏捷团队,可能都遭遇过迭代计划频繁变动,经常有临时任务插队,团队成员的工作状态被频繁打破等问题;
从实践角度来说,解决这些问题需要团队在迭代前有着清晰的规划,并确定迭代时间和目标,将需求拆解的足够细,与业务方达成协议,在迭代后根据准确的度量来发现问题持续改进;
而从工具的角度来看,PingCode Project 则更有助于以上实践方法的落地,比如:
在迭代开始前,团队可以将已梳理完成且优先级高的用户故事规划到迭代看板内,并规划出项目/产品版本及发布范围,让发布更有计划;
在迭代会议,则能够帮助产研团队更好的确定迭代时间和目标,细化用户故事为更小的开发任务,提供敏捷估算器辅助估算故事点,规划形成Sprint Backlog,填写预估工时。(燃尽图我们将在下面讲到)
Sprint Backlog
将用户故事细化成更小的开发任务
过去产研团队在各个开发环节的工具中频繁切换,且低价值、重复性、手动性任务团队浪费较多时间;
在开始迭代后,如何解决各环节工具中频繁切换,让团队有更多的时间专注在有价值的任务成为很多团队提升效能不可回避的问题。
开发关联:PingCode 除本身覆盖项目管理全生命周期的能力外,还通过应用市场与其他工具集成,所以迭代过程中的代码、持续集成、测试用例、缺陷、文档等,都可关联对应需求,信息在需求页面均可统一获取;
自动化能力:如果迭代过程中,某个需求下的子任务都完成了,PingCode Flow 将自动改变该需求的状态,类似的场景还有很多,就比如自动创建分支、自动配置页面权限等等;PingCode 提供了非常多的自动化规则模板,同时用户也可以自行创建。
工时统计:除此以外,PingCode 也支持团队在迭代过程中填写、统计预估工时、实际工时,形成项目/团队工时统计视图;
该环节痛点: 在以往,敏捷团队可能更多是使用Excel定时统计需求进度,费时费力还容易出错。
每日站会核心是围绕以下三个问题展开:
但每日站会不是任务指派的会议,也不是报告的会议,而是为了沟通状态、减少其他会议、发现开发过程中需要移除的障碍、促进快速地做决策、提高开发团队的持续改、优化开发团队达成Sprint目标的可能性。
以往这一环节,团队可能更多是使用 Excel 定时统计需求进度,但这种方式费时费力还容易出错。
在 PingCode ,团队可以通过任务板/故事板,查看每个成员正在处理的任务,确认迭代范围变化情况,快速掌握团队进展。
除此以外,团队还可以通过迭代概览、迭代燃气图等统计报表,查看当前迭代进度,识别迭代风险。
迭代评审会议在 Sprint 快结束时举行 ,这个事件是让开发团队展示他们在Sprint中取得的成就,根据DoD“完成的定义”和验收标准,验证增量。
所以,当任务负责人演示工作成果时,可能会提出一些缺陷,而这个时候团队可以直接在用户故事上直接创建缺陷/Bug,并确定Bug紧急度。
该环节痛点:以往可能缺乏可靠的研发数据作为持续改进的基础;
回顾会议专注于团队和团队的流程,它一般围绕以下三个问题展开:
使用 PingCode 后,产研团队完全可以不凭借经验感觉和有限的数据分析复盘,因为 PingCode 不仅每个Scrum 项目内有针对该项目的报表。
还具备专门为效能度量而打造的子产品Insight,提供自动采集效能数据能力和体系化效能指标体系,能够帮助敏捷团队基于准确数据进行持续改进。
除此以外,在迭代回顾会召开过程中,团队还可以借助 PingCode 将“当前迭代做的好、不好及需要改进的计划”,记录进迭代回顾板,做到持续跟进。
至此,一个完整的 Scrum 迭代过程就基本结束。
通过对敏捷框架的逐一盘点,敏捷项目管理各环节痛点的对应,大家也能基本了解PingCode 这款工具对敏捷开发项目管理的支持程度,是否能满足自己需求。当然这些也仅是我们团队的测评,是否满足其他团队,还需大家亲自体验。
PingCode 官网
了解敏捷开发: 什么是敏捷开发? | 瀑布与敏捷的区别 | 敏捷宣言及相关解读 | 国内外主流敏捷开发框架对比 | 主流敏捷框架之Scrum 敏捷开发中的模式介绍 | 敏捷开发的优缺点 | 待续...
落地敏捷开发: 敏捷开发模式 Scrum vs Kanban如何选择? | 国内外最著名的10个敏捷开发项目管理工具盘点 | 从8人到100多人的敏捷实践分享 | 百人左右团队如何做好敏捷开发? | 待续...