在自己工作中有过几次敏捷的实践从懵懂不知何物到步步踩坑再到顺利实施完整的流程当中的滋味只有自己最清楚。一、懵懂的“敲门期”在一个跨团队开发的项目中自己充当着本地业务需求对接角色需要把建设方也就是甲方的业务需求拆解成开发需求传递给异地的开发团队。在得知该开发团队是采用敏捷开发模式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、用户故事验收一般我们会把用户故事写在纸张上背面后些一些验收标准。各公司实践中标准各异一般来说至少有正常路径和异常路径这两点。以用户提现T1到账节假日顺延为例正常路径用户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、优化自己的敏捷需求管理技能。