回顾敏捷实践踩过的坑：如果重新做，我会这样做（一）

在自己工作中有过几次敏捷的实践，从懵懂不知何物，到步步踩坑，再到顺利实施完整的流程，当中的滋味只有自己最清楚。

一、懵懂的“敲门期”

在一个跨团队开发的项目中，自己充当着本地业务需求对接角色，需要把建设方（也就是甲方）的业务需求拆解成开发需求传递给异地的开发团队。在得知该开发团队是采用敏捷开发模式，scrum框架实施项目管理的时候，我被推到了一个产品负责人的角色（Product Owner）。

当时就是一个感觉，“懵逼”！但也觉得非常有趣和有挑战性，因为之前都是使用瀑布开发模式进行项目管理，敏捷开发模式让我觉得充满新奇和挑战性。好在当前产品列表已处于清空状态，交接前的所有需求都已完成，因此我不需要在考虑历史遗留问题。但是scrum的流程，让我感到自己的知识库需要更新。

1、需求传达方式改变

在平常的开发过程中，我会对需求调研中的材料进行筛选、合并等一系列优化操作，把客户的业务需求整理出来，在与对方确定后，再把业务需求转成供研发团队进行研发的开发需求文档，整个过程一般需要一个多月到三个月（大项目）。有时因强势客户的需求变更，中途调整需求，导致整个项目实施进度受到严重的挑战。这时不仅要面对客户的步步紧逼、催交付，还面临着开发团队的因此加班的怒火，感觉简直了。

在scrum中，我惊奇地发现，原来需求的表述，不需要那么多业务流程图，那么多繁琐的子项，就以一个用户故事就能表达一个功能需求。而且团队也有共识，产品列表可以追加用户故事。当时相比于scrum master 和研发团队，我这个敏捷PO其实是个菜鸟，不仅敏捷理论贫乏，而且日常操作也经常有偏差，多得大家的谅解，不然真的无地自容。

2、合作方式不同

在传统的项目管理中，作为项目经理，我经常参与到项目的各项工作，比如架构设计、接口设计、功能点设计，甚至编码。但是我发现scrum中，scrum master就是一个教练的角色，比赛时就在场边指挥但是自己不上场，研发的事情交由开发团队（开发+测试）负责。当然我看到开发团队是有一个架构师负责带队，也不是特别担心，要知道这个scrum master也是一个非常有经验的研发项目经理。

而我这个PO其实和传统的产品经理没太大差别，可能因为我是技术出身，因此很多时候总是优先想到的是技术能不能实现，很多时候这点会在和客户沟通需求时受到质疑。因为对方需要的是把业务做通，而技术可不可行并不是对方优先考虑的。也是因为吃得亏多了，我的思维模式也发生了改变，与客户交流的过程也更为顺畅。

3、交付频率不同

传统it项目，经常是在验收是给与客户一次性演示，然后预留半年的试运行期去生产跑业务，并修改bug。但是针对一个开发周期一年到两年的项目来说，如果需求理解发生偏差，可能导致整个项目无法完成验收，我经历过的项目中就有一个银行的呼叫中心项目，因动态表单无法满足对方的要求而导致项目无法验收通过，后面申请立项做免费的补充开发，因公司对补充开发的成本过高，导致审核不通过，从而项目夭折，白做了一年。而且对项目成员的心理打击是非常大的。

scrum则是在迭代计划会议抽取产品列表中的部分内容，放置到sprint的冲刺任务列表（Sprint backlog）中。然后在sprint周期内完成开发和测试，经过PO的验收后，进行版本发布，然后接受客户的反馈，并把反馈内容放进下一步迭代中进行持续的优化。这样在短时间内，把项目中紧急而重要的功能交付给客户，得到客户反馈，从而把隐藏的需求理解偏差尽早暴露，可以减少优化的成本。

二、如果重新做，我会这样做

在担当PO时候，我因初次接触敏捷开发，因此无论是理论还是实践经验都很缺乏。如果重新做，我会对scrum的需求管理方面进行优化：

1、认知用户故事

用户故事是可用于陈述业务价值的一种简便格式，旨在帮助业务人员和技术人员双方都能理解需求。也就是说用户故事是要体现出业务的价值的。

2、INVEST原则

一个好的用户故事，应该遵循六大原则

Independent(独立的):分解出来的用户故事要尽量减少依赖性，成为一个独立的单元。

Negotiable(可商议的):用户故事是一个共识，但可继续进行协商，过多的细节会限制客户的沟通。

Valuable（有价值的）：对该用户故事的实现或者交付是以商业价值为目的。

Estimable(可估算的):可以估算出故事点数目。

Small(足够小的)：用户故事在一个迭代周期内可以完成，不能跨迭代周期。

Testable（可测试的）：可以确认用户故事可以完成的。

3、用户故事验收

一般我们会把用户故事写在纸张上，背面后些一些验收标准。各公司实践中标准各异，一般来说至少有：正常路径和异常路径这两点。以用户提现T+1到账（节假日顺延）为例：

正常路径：

用户2022年5月26日提现，2022年5月27日到账。

异常路径：

用户2022年6月3日提现，2022年6月7日到账。

用户2022年6月10日提现，2022年6月13日到账。

4、用户故事树

进行需求调研收集业务需求，PO会因树状结构从上往下进行分解得到整个用户故事树，在完善时，我们也遵循着从下往上进行的原则。然后和客户进行沟通确定整棵树。

5、打磨用户故事

我们在梳理单个用户故事的时候，首先要界定出业务边界，一般会以用户角色为参考点。

比如一个旅游网站，那么我们可以区分出会员、游客、管理员三类角色，然后把业务划分出相关的模块。游客可以搜索景点、附近酒店等，会员可以预定酒店，管理员可以发布酒店信息、查看报表。

常用的用户故事描述模板：作为**用户，期望**，以便于***。按这个格式提炼出相关用户故事。而我们提炼出的用户故事，也许粒度太粗，我们还需要继续分解，例如：

针对会员预定酒店这个需求，我们可以得到的用户故事：

作为会员，希望根据按关键字来查询酒店信息，以便于选择酒店。（选酒店）

作为会员，希望能查看酒店的房型信息，以便于选择房型。（选房型）

作为会员，希望能预定某酒店的某房型信息并开发票，以便于出行准备并报销。（预定酒店、开发票）

作为会员，希望线上支付或者到店支付房款，以便于付款。（付款）

.....

按实际需要，可以继续拆分下去。而拆分的原则是颗粒度要相同。比如“作为管理员，希望对会员信息查询，以便于会员的管理。”和“作为管理员，希望会员信息进行管理，以便于会员生命周期的跟踪。”，信息管理包括了会员信息的添加、修改、删除和查询，包含了会员信息查询的用户故事，因此颗粒度不同。

6、编写用户故事

用户故事一般以表格来梳理，包括了id(有排序的效果，越前的优先级越高)、故事名称、故事描述、如何演示等信息外，还有其他辅助信息，因各组织的要求有所不同。

编写用户故事时，只关注那些重要的细节，具体由需求交流时客户的诉求来决定。

7、估算故事点

故事点是产品负责人与客户沟通进行的一种预测性结论，注意故事点并不等同于工作量，两者之间是需要进行换算的。

首先，故事点估算的方法：

抽取当中一个比较确定的用户故事进行估算，得到的故事点作为整个需求列表故事点的参考，并把其余用户故事的需求点进行估算，最终得到全部用户估算的故事点。

其次，确定团队开发速率：

让研发团队资深人员对某个用户估算进行工作量估算，比如查询“作为会员，希望根据按关键字来查询酒店信息，以便于选择酒店。”这个用户故事的故事点为2，工作量4天，那么团队的开发速率为2。这时候故事点和工时的换算关系就确定下来了。

再次，确认用户期望完成工期、团队完成时长的吻合度

团队完成时长=用户故事点总数*团队开发速率

如果用户期望完成工期 >= 团队完成时长,则吻合，否则反之。

8、无法如期完工常见解决方法：

a.对次要的用户故事进行延期交付。

这种方法需要与客户协商确定，很多情况下是走不通的。

b.简化用户故事。

在线支付包含了支付宝、微信和银行卡等方式，可以和客户沟通，只做微信支付。这种方法概率性地通过，而且是简化的程度是打折的。

c.增加人手。

只能作为阶段性的方法实施，人数不能添加过多、周期不要过长，不然产生的成本是很大的。

三、结语

作为首次接触scrum并担任PO角色来说我是幸运的，因为有一个经验丰富的团队支撑，为我解决一个菜鸟犯得很多错误。如果可以重新做这个项目，我会从两个方面优化：1、敏捷的价值观和理念的掌握，从根本上让思维进入敏捷模式。2、优化自己的敏捷需求管理技能。

回顾敏捷实践踩过的坑：如果重新做，我会这样做（一）相关推荐

weex的实践踩坑日常（一）
先简单说下weex吧,官网的介绍是基于当代 Web 开发技术,使用同一套代码来构建 Android.iOS 和 Web 应用.具体来讲,在集成了 WeexSDK 之后,你可以使用 JavaScript ...
android 沉浸栏灰色,Android 沉浸栏实践——踩坑
当前开发环境:Android Studio 2.1.3,compileSdkVersion 24,buildToolsVersion "24.0.2",support:appcom ...
20210223-21款Mac Pro M1安装ps和pr,个人实践有用，不需要付费，自己踩过的坑
自己安装M1芯片的PR和PS,踩了不少坑,很多百度链接下载的软件,都是加密的dmg,解压还需要收费,非常不解,所以在此分享给大家,免费的下载链接,另外附上安装方法: 废话不多说,<苹果电脑M1芯 ...
震惊了！关于JAVA复习的最佳敏捷实践！进BAT就是个毛毛雨！
引言话说,几个月前有个朋友是这么和我说的. 但是呢,大家也知道,人很多时候往往是有心无力.所以呢,他刚好找到了我.我当时突然灵机一动,决定用敏捷开发的方式对其进行培养. 敏捷最大的特色是迭代式开发, ...
QCon演讲| 从团伙到团队，PingCode研发团队敏捷实践血泪史
文章整理自PingCode基础平台部总监徐子岩 QCon大会演讲:(大会视频及PPT文末获取) 当研发团队发展到新的规模或阶段,原有适应的开发管理模式都会面临新的瓶颈和问题,这个时候就需要去引入新的 ...
C/C++ 踩过的坑和防御式编程
相信你或多或少地用过或者了解过 C/C++,尽管今天越来越少地人直接使用它,但今天软件世界大多数软件都构筑于它,包括编译器和操作系统.因此掌握一些 C/C++ 技能的重要性不言而喻. 这场 Chat ...
阿里敏捷教练全面解析淘宝直播敏捷实践之路
背景介绍阿里很少提敏捷转型或DevOps,阿里是强业务驱动的,不管用什么办法,一定要达到业务目标. 我来自敏捷教练团队,我们的职责是帮助团队拿结果.这里的团队不限于研发团队,我现在支持的团队包括销售 ...
要想不踩SaaS那些坑，得先了解“SaaS架构”
摘要:围绕当下许多企业青睐的SaaS应用开发,华为云开发者技术服务工程师程泽在DTT首期带来主题为 <SaaS云原生应用典型架构> 的DTT首期直播分享. 本文分享自华为云社区<DT ...
AWS Device Farm介绍及Appium踩过的坑
本文记录了在AWS Device Farm上进行Appium TestNG进行手机应用UI自动化测试的流程及遇到的问题,及具体的解决方法.同时记录了使得测试脚本更稳定的一些代码写法. Device F ...

回顾敏捷实践踩过的坑：如果重新做，我会这样做（一）

回顾敏捷实践踩过的坑：如果重新做，我会这样做（一）相关推荐

最新文章

热门文章