关闭

关闭

关闭

封号提示

内容

首页 故事卡片限制了敏捷.doc

故事卡片限制了敏捷.doc

故事卡片限制了敏捷.doc

上传者: Gordon中起 2018-06-14 评分 0 0 0 0 0 0 暂无简介 简介 举报

简介:本文档为《故事卡片限制了敏捷doc》,可适用于工程科技领域,主题内容包含故事卡片限制了敏捷人们使用故事卡片的方法不对。我知道这么说很大胆但我认为大部分人使用故事卡片的方法确实不对。就我工作和指导过的团队而言这点毫无疑问。符等。

故事卡片限制了敏捷人们使用故事卡片的方法不对。我知道这么说很大胆但我认为大部分人使用故事卡片的方法确实不对。就我工作和指导过的团队而言这点毫无疑问。不要误解我的意思相比我们过去常用的传统的具体规范文档来说故事卡片(storycards)是有很大提高但我觉得我们可以做得更好。我指导大家用传统方式来创建故事卡片已经很多年了但发现故事卡片正限制着敏捷。故事卡片是敏捷开发中用于跟踪需求的一种常用工具这些需求可以来自业界、来自客户或来自产品经理。但目前故事卡片常用的格式会令我们放错重点、得出错误结论、浪费时间、浪费机会。其实我们只要对故事卡片做一个巧妙而重要的改动就能克服这些问题并获得在市场中的优势。大概的团队会采用下列格式来创建故事卡片:作为(角色)我想要(功能或特性)以便于(商业价值)以前我在西雅图FUEL:Coffee公司任职时跟一帮朋友讨论过包括敏捷、精益和生活在内的各种话题。我们谈了很多方面主要是围绕着产品经理的角色与重要性。我们还讨论了精益创业(LeanStartup)运动以及它如何影响了敏捷开发。正是在那次对话中我开始为大部分敏捷方法没有关注到开发和交付之前与之后的活动而叹息。是的理论上敏捷方法会关注那些活动但实践中并没有连贯的行动来支持它(当然除DSDM以外)。产品经理们只是把故事卡片按客户价值归类存放仅此而已。故事的反馈和修改主要发生在向产品经理演示产品的过程中。这让我看不下去了。故事卡片如果不是由客户(一个真正的客户)直接创建、而是由产品经理或客户代表创建的话那么它所记载的故事就是假故事。产品经理创建的故事不过是假设和符合专业能力的猜测而已是他们自认为客户想要的东西。产品经理们试图理解客户的心理。但在生产出产品或服务之前他们不会真正知道市场反应怎么样。所以若采用“作为我想要”这种无条件的陈述格式那么就容易造成误解让我们误以为产品经理真的知道客户想要什么而忘了那只是个假设。由于每一个特性都需要一定工作量去完成有的多一些有的少一些。假如把故事写成“作为我想要”这种无条件陈述格式我们会误以为他确定是真的。如果最终我们发现这个假设是错的(经常如此)那时我们可能已经浪费了很多工作量。就算现在的项目不像过去那样经常到了部署阶段才成为败局(别忘了福特公司的“埃德赛”汽车和微软那个会说话的大头针)但即便有办法来检验假设仍然会浪费不必要的时间和精力。可是既然它从未被说成是一个假设那么就没有人会去质疑它。如果由项目经理来创建故事卡片我认为采用如下格式更好:我们(或我)认为(客户)想要(功能与特性)以便于(商业价值)为验证之我们将(假设检验)把第一行改成“我们认为”这样你就知道这个故事是假设了。如果只说“作为”的话大家会误以为这是事实、肯定对客户有价值。说“我们认为”是在提醒大家我们说的只是假设。如果一个故事真是由客户创建的而且故事真的是他们“作为(客户)”讲出的那么完全按照传统格式的故事卡片就行。甚至可以把客户的名字也写在上面。“我是张三我想要”这样更好。这样你不仅有真实客户还有人的真名与这则故事相关联。当你在开发过程中对需求有疑问时就可以去找这个人讨论。按照这个方法我们将有两类故事:()真实客户故事格式为“作为”()有待检验的假设性故事格式为“我们认为”。对于第二类故事要格外小心因为你不确定它的有效性。如果这个故事规模很大很复杂的话那么团队在投入精力去开发它之前应当先认真考虑有没有简单办法来验证这个假设。如果你用物理黑板或者你的管理软件支持的话我强烈建议采用不同颜色或视觉上有显著差异的卡片来区分假设性故事与真实客户故事。这样就容易看出精力投入到了哪里。都是真实客户故事,或者基本上是创新性假设检验,创新性假设检验未必是产品或服务的实际开发而是验证客户要不要这个产品或服务。这是精益创业的核心原则。问题这个产品能造出来吗,”而是“应该造这个产品吗,”所以我们围绕着概念而不是产品或服务来构造假不是“设检验。EricReis在他的书《精益创业(TheLeanStartup)》中举了一个Groupon的例子。Groupon在初期没有实现自动化没有高性能服务器也没有高速网络连接甚至计划中的都不是一个团购平台。在尝试创建一个叫做“ThePoint”的病毒式营销平台失败后Groupon团队建起了一个提供匹萨店打折优惠券的网站。他们人工发出电子邮件然回复后再把优惠券以PDF格式发出去。就这么简陋~没有自动回复没有强大的电邮营销自动系统。你的后等收到故事也可以这么做。“为验证之我们将”用于陈述你进行检验假设的步骤。这样做的好处是它可以在演示或部署结束前完成验证得出故事成功与否的结论。若是成功的那么很好你猜对了~若是不成功你也有收获你至少证明了这条假设是错的现在该换个方案尝试了。你得到了经验~你知道了客户喜欢什么不喜欢什么而且理解了客户和变化这也是敏捷所讲究的。故事之间也可能存在潜在冲突。现实中人们想要的东西未必一致。所以在真实易懂的故事卡片和进行故事验证(用户需求或假设)之间你会发现存在矛盾。你可能会有两个真实客户他们想要不同的东西或者你的假设性故事与真实客户故事相悖。在真正的创新工作中可能会碰到这样的情况。你该怎么做,这是产品经理该管的事。亨利福特有一句经典名言如果我当年去问顾客他们想要什么他们肯定会告诉我:“一匹更快的马”。假如你正在创造一个真正突破性的东西那么普通用户给不了你提示。这正是为什么你要用假设性故事来探求客户还没有意识到的新想法。敏捷方法的一个优势在于它是持续改进的。我记得当我第一次提出增加“以便于”的时候那对团队来说是一个伟大的突破。增加“以便于”这句话有助于令我们在创建故事时专注于客户价值进而专注于持续交付对客户有价值的东西。明确区分用户需求与假设检验将有助于团队理解故事的重点:提供用户需要的服务或者验证假设。这可以让产品经理看清精力放在了什么上面。一个组织如果要创新、要取得重大突破它的假设性故事会多于客户需求。通过为假设性故事采用不同的卡片格式我们可以在有效性和透明性上得到改善。查看本栏目更多精彩内容::wwwbiancengcnProgrammingproject

用户评论(0)

0/200

精彩专题

上传我的资料

每篇奖励 +1积分

资料评价:

/4
0下载券 下载 加入VIP, 送下载券

意见
反馈

立即扫码关注

爱问共享资料微信公众号

返回
顶部