传染

跟@lidingshan和@大熊Stanley一起回顾了从2007年以来参与敏捷社区的历程,如何保持社区志愿者组织的活力,如果激发不断的创新,这其中还是有很多可以反思的。对我们个人发展、还是公司以及社区组织会有很多借鉴意义。我们把整个过程以及我们的反思做成了一个话题分享,周末会在土豆网作第一次分享。我们的题目是“传染-部落型社区对组织及个人的启示”。

活动名称:上海社区经理培训和交流活动之二。

时间:5月12日上午九点半到十二点

地点在土豆网(斜土路1238号x2创意园区6号楼土豆网)

我们作出的敏捷社区发展Timeline

通过串整个过程,回顾过程中的成功和失败以及发现里面的Pattern,我们发现对于个人的启示其实可以用一个系统图表现

对组织的启示其实也是一个系统图

共同工作/创作才会有更多的Insight和学习

Share

2012上海社区组织者聚会

来自于上海各个IT社区的核心组织者终于有机会聚到一起。今天在大众点评网的食堂,来自TopGeek, Thinking In Lamp,PMCamp,GTUG,Flash,TechYizu以及敏捷社区的核心组织者做到了一起,讨论推动和整合上海社区进一步发展的议题。

各个社区都带来了他们标志性的纪念品。

大家一起回顾了各个社区发展的“巅峰时刻”。

从这些颠峰时刻中,我们发现打造健康的IT社区的成功因素,包括

* 团队的健康发展,利用老组织者的经验和新组织者的拼劲。
* 互联和互通,建立人与人之间的联系
* 梦想和机会
* 探索与迭代,也就是持续改进

大家对三年后的社区也有很多期待,包括整合的资源,建立统一的品牌,不同社区组织者的组织,社区经理,等等。

为了实现梦想,大家集思广益,给出了很多点子。

梦想虽好,关键是落地,第一步已经迈出。

  • 下个月我要和Mike Li一起分享一个关于社区团队建设的话题。
  • RubyCon也要启动
  • 还有开源社区也列出了具体的一个月内的时间表

违反规则的后果很严重

更多照片参见 我的Picasa相册

Share

流星来了

很多公司和团队曾经有过辉煌的历史,而且这些辉煌的历史是使用一些繁重的开发过程创造出来了,看起来这些过程对他们来说是有效的,这样的团队也需要变么?也需要向敏捷转型么?
也有些公司引入了一些敏捷实践,持续集成也建起来了,这就够了么?是终点了么?
还有些人问我现在敏捷挺火的,coaching的项目很多,那过两年,敏捷不在火了,我该怎么办?

针对这些问题,也是总结了去年学到的,看到的东西,我写了一个talk,谈一下当下社会中的生存策略。下面是这个分享的幻灯片。

Share

二月Product Owner认证课程

二月28,29号跟吕毅一起Co-train一次Product Owner认证课程。地点是在上海市江苏路的舜元国际会议中心。以下是课程介绍

通过两天的CSPO课程,您将会学习到Scrum的框架和如何成为在该框架中有效工作
的Product Owner,包括理论和实践。
第一天,我们会从Scrum基础开始,讲述它的历史、敏捷宣言和经验型流程控制在 复杂性项目中的应用。在概要阐述Scrum的框架后,我们会对Product Owner这一 角色做详细阐述。我们会学习到Product Owner的多个重要方面。Product Owner 需要理解价值思考和如何应用在产品开发中;Product Owner需要和不同的利益相 关人有效合作;Product Owner也需要理解质量思考和遗留产品的影响。

第二天,我们会进入Product Owner这一角色更具实践性的方面。我们会从展望愿 景开始,逐步创建Product backlog,包含价值和成本的估计、优先级排列以及与此 对应的合适细节粒度。基于Product backlog,我们会来计划和管理版本。然后,我 们会讲Product Owner如何与团队合作以迭代的方式交付。最终,我们会看如何开 始过渡成为一个好的Product Owner。
课程适合希望大体学习Scrum并深入学习Product Owner这一角色的人群参加。

注册请到Scrum Alliance官方网站

Share

回顾2011与展望2012

2011年对自己来说是一个十分有意义的一年,无论是在个人、职业还是知识层面。有必要做一个的retro,同时也展望一下2012年。

过去的一年感觉总是在忙忙碌碌中,比较乱,但是回头梳理了一下,主要的研究方向主要有三个分别是教练与引导技术,技术以及思维变革方面。

 

教练与引导技术
组织前年敏捷之旅的一大收获是认识了不少跟我有类似价值观的,非IT领域的伙伴,主要是“一块儿”和“一道儿”团队。他们都是教练技术以及引导方面的专家。通过与他们的交流,参加并且在客户项目中一起合作学习了很多这两方面的技术、技巧以及方法。对我来说,真正启蒙是参加去年四月1号到3号的“一块儿”生日Party,”Yes, I’m In”工作坊。三天的工作坊让我对“欣赏式探寻AI”有了切身的体会,同时也亲身体验了很多的Facilitation方法。接下来花了很多工夫提高自己这方面的认识与技巧,主要是读了很多这方面的书。同时也利用为客户服务和社区活动的机会做了很多这方面的尝试和实践。
  • 谁说我们不能一起做决定(繁体)- 这是一本引导方面的大全,如果引导只看一本的话,应该就是这一本了。
  • Inner Game of Tennis – Timothy Gallwey是一个网球教练,他是教练技术的鼻祖,教练并不是教给其他人怎么做。很多时候,只要把问题指出来,coachee就能自己找到不错的方案。
  • 画个画,说得更清楚(繁体) - 很想掌握在Scrum Gathering上海帮我们做图像纪录的Ripley的技能,不行的是我天生不会画画。Ripley跟我说,你总会画直线和圆吧,这已经够了。然后再看看这本书。这本书对于一个从没有接触画画的人来说,算是一本快速入门手册。
  • Coaching Questions – A Coach’s Guide for Powerful Question Skills。一个有经验的教练应该时刻都在问问题而不是提供答案。但是如何问问题,该怎样问,也有学问。
  • 引导者工具箱(繁体)- 很多,很全的Facilitator工具,是我的手头引导手册
  • Open Space Technology – A User Guide,现在开放空间会议越来越受欢迎。开放空间的发明者写了这本书,系统的介绍了应该如何去引导开放空间会议。
  • How To Give So They Get It – 著名的“Training From The Back Of The Room”的作者Sharron Bowan的一本关于应该如何“教”的小书。
技术
技术也是去年的一个主要的着力点,主要精力是在TDD, 重构,ATDD,以及Ruby。主要是通过读书、参与开源项目,Kata,以及客户项目。从去年早些时候开始有计划地练习Kata,发现Kata真是一个学习TDD以及编程序的好东西,通过对小程序、小算法的不断重复练习,能够加深对语言、算法、重构甚至IDE使用的理解。除了Kata和小程序,还参与了一个社区网站的开源项目AgileWizard,虽然最终由于种种原因没有坚持下来,但是还是尝试了一些新的工具和想法,比如BDD, SpecFlow, Rake, ASP.Net MVC, XUnit等。近两年来把业务与技术实现结合的趋势越来越明显,因此ATDD, BDD, Feature Injection, Spec by Example一类的想法不断涌现。在Agile Conference 2011,这一类的话题也炒得很热。这也应该是我在今后几年应该继续关注的热点。也读了不少这方面的书。
  • Specification By Example,我以前公司的同事们(Steven Zhang, Jackson Zhang, Stone Shi)正在翻译这本书。这是一本十分系统介绍把业务,开发和测试相结合的书。Gojko是这方面顶级专家,在书中他系统地他整个流程分成五步,确定目标,根据目标确定范围,通过示例描述需求,自动化示例,形成活的文档。回想起来,这本书对我来说最有用的是那一条条的建议,一个个反模式以及如何利用SBE撬动组织的敏捷转型。
  • Growing Object Oriented, Software, Guided by Test。这是一本不可多得的把面向对象与TDD结合在一起的书。很多人不喜欢Mock,但是Steve Freeman在书中澄清了Mock的意义,以及应该如何使用Mock,另外对于如何通过测试先行的方式去推动架构以及面向对象的设计,书中给出了很多中肯的建议。更难得的是,Steve用了Specification By Example的方式,利用实例一个个原则把整个过程叙述得很清楚。
  • Working Effectively With Legacy Code。我们日常杰出的都是Legacy Code,如何把一堆乱麻的代码整理好,这是唯一一本。
  • Continuous Delivery。前年和去年很火的书。
  • Feature Injection。一本很有意思的漫画书,免费的。Chris Matts通过这个有趣的方式,解释了他对整个软件开发过程尤其是PO与开发团队之间的合作的认识,给了我很多的启示。
  • Refactoring,重读经典老书
  • The Art of Unit Test,我上半年参与了这本书翻译版本的审阅,这是一本相当不错的TDD入门读物。
  • TDD .Net with FitNesse,一本很好的关于FitNesse的书,也是Gojko写的。
  • Programming Ruby 1.9,读过几遍了,但是还要不停回来翻翻,Ruby语言学习必备,同时也是很好的参考。
  • Everyday Script with Ruby,从Tester视角学习Ruby
  • The RSpec Book
  • Scripting with Ruby on Mac,可惜AppScript已经不被维护了,还是比较难用的。我用它来操纵Mac上的App。
  • 卓有成效的程序员
  • Shell Scripting Primer
思维变革
去年看了不少关于思维变革方面的书,虽说跟敏捷无关,但其实对我影响甚至比前两类的书还要多。
  • Switch – How to Make the Change When Change is Hard。Seth Godin, Dan Godin现在已经成为我最喜欢的作家。他们的每一本书都是那样的一针见血,与众不同。Switch借用“象与骑象人”来隐喻组织以及引领组织变革的变革者,并分别给大象以及变革者很多有用的建议。
  • Linchpin – Are You Indispensable? Seth的另一本书, 绝大多数企业的期望把工作、流程、人员标准化,从而获得最大的利润。但是对于每一个个体来说,就不是一个好消息了,我们绝大多数人在公司里面做的工作,都可以被更便宜的人替换掉,我们的工作很容易被外包。这本书给了很多生存建议,让我们每个人变得不可或缺,不那么容易被外包。
  • The Black Swan,我们总是认为事情是可以预测的,但是人们被黑天鹅事件(那些以为可以被预测的不可预测事件)一次又一次地击中。面对越来越多的这类事件,我们也应该改变自己的思维方式。
  • The 80/20 Principle – The Secret to Achieving More with Less。无论是工作还是生活,书中都给出了很多实践意义的建议。
  • Think Like Da Vinci,Da Vinci是“The Book of Genius”这本书根据”Originality”, “Versatility”, “Dominance-in-Field”, “Universality-of-Vision”, and “Strength and Energy”评选出的人类有史以来最大的天才。他的天才并不是偶然,是因为“好奇心”,”通过不断的试验,从错误中学习”,“不断地提高自己的感觉”,“拥抱不确定性”,“全脑思维”,“Corporalita”,”系统化思维”。
  • 粘住 (Made to Stick),又一本Seth的书,如何让你的观点和想法在别人的脑子里面留下更多的钩子,从而留下更深刻的印象。SUCCESs原则(Simple, Unexpected, Concrete, Credible, Emotional, Stories)。
  • Lean From The Trench,Scrum&XP from the Trench的姐妹版,个人认为这一本要比第一本更好。
  • Succeeding with Agile,Mike Cohn的敏捷转型。
  • 浪潮之巅,从硅谷的IT发展历史中,我们可以学到很多可以借鉴的东西。
  • 活着就是为了改变世界,我们每个人都可以从乔布斯那里学到很多东西。
  • Blink – The Power of Thinking without Thinking。如何以及怎样立刻作出判断。
  • Are Your Lights On,很值得多读几遍的关于问题的书。

除了业务方面,很大一部分经历花在了社区建设方面。全年参与组织了十八个会议以及很多次的社区活动,也认识了更多的热心人。

  • 敏捷之旅已经越来越大,从去年的8个城市,扩展到了14个城市。尤其是上海敏捷之旅,全新的组织者团队给人耳目一新的感觉。
  • 由去年敏捷之旅核心组织者组织的Scrum Gathering也取得了空前的成功。
  • 上海的本地社区活动在每个月第二个星期持续地发布,而且组织者轮换主持。

去年之最:

最喜欢的工具:IPad,它已经变成我工作和生活的一部分,用它来看书、上网、读杂志、记笔记、照相。
最喜欢的团队:敏捷之旅上海组织者团队,我深深被这些社区贡献者的激情和创造力所折服。
最喜欢的国际会议:盐湖城敏捷大会2012,无论是内容,还是形式都无愧于最好的敏捷大会。
最喜欢的国内会议:Scrum Gathering上海,国内目前最好的敏捷会议,无论是内容、还是组织,当然还有Ripley的图像记录。
今年最喜欢的一本书:Switch

 

不足之处:
  • 去年没有做到Linchpin中要求的Frequent Ship,也就是频繁的发布自己的想法。Blog更新不及时,除了在客户现场,很少分享新的话题。
  • 没有做到Think Like Da Vinci中的Frequent Reflection,反思的不够及时而且频率也不够高。
  • 学习Unknown Unknown,整个去年花在读Blog, Twitter以及讨论组的时间很少,因此感觉对新东西更新不如以前了。
总结一下原因,还是自己时间管理不够好,头绪太多,同时工作安排得也太满。看来明年要慢一些,同时要平衡地计划自己的时间,处理好Unknown Unknown, Known Unknown, Unknown Known以及Known Known之间的关系。

 

展望2012
在2012年我想重点关注三个领域
  • User Centric Design
  • Requirement Collaboration
  • 技术(主要是Evolutionary Design, Modeling)

另外希望练习>6个Kata,参与一个开源项目。

工作方面,期待与公司的同事(Lv Yi, Terry Yin, Steven Mak)一起碰撞出更多的火花,把工作和社区向前推进一大步。

 

Share

敏捷上海1月份聚会

敏捷上海聚会将于一月份第二周周三(1月11日)晚上在English First办公室举行,地点是在铜仁路。这一次我们想做得与众不同一点儿,借鉴一下Open Space,把我们的聚会从Push方式,转变为一部分Pull。也就是说,不再仅仅让组织者寻找讲师分享话题,由这一次的参加者投票选出下一次感兴趣的话题。这些话题可以是自己个人感兴趣的话题,可以是一直想学习的东西,也可以是现在团队中遇到的困难。然后大家一起对得票数多的议题进行切分, 分成几个小问题,然后分组认领,花一个月的时间在组内研究、学习。在第二次聚会的时候每个小组分别去分享。跟大家一起学习的效果肯定要比独自一个人研究要好得多。

举一个简单例子,对于ATDD工具,我们可以谈Cucumber,可以谈Concordion, 可以谈SpecFlow,可以谈Gerkin语法以及FitNesse/Slim等。对于Retro,我们可以研究游戏,研究思维工具,研究常见的臭味,研究引导手法等等。如果你有什么感兴趣的议题、有什么想要学的东西,欢迎带到敏捷上海聚会,我们一起来研究。

另外也预告一下下一次的两个分享,一个是上海贝尔@何勉的第五项修炼阅读分享,很多人都说Peter Senge的这本书是好书,可以很多人读了几遍也读不懂,@何勉将给我们分享他研究第五项修炼多年的感受。第二个分享是Autodesk的@姚若舟给我们带来的Transformation Priority。在TDD实践中,TDD不难,真正难的其实是如何设计一个个的测试用例,然后利用用例去推动设计,而这个用例的设计是否有优先级,实现了一个测试用例之后,如何去选择下一个测试用例?Bob大叔写了一篇blog “The Transformation Priority Premise” (可惜被墙了)。@姚若舟会用Bob大叔的例子Wordwrap kata去给我们展示整个过程,以及他的思考。
想要了解更多敏捷上海聚会,可以加入敏捷上海讨论组(agileshanghai@googlegroups.com),也可以关注微博http://event.weibo.com/308758
Share

敏捷之旅2011上海站回顾

今天晚上在Autodesk办公室,敏捷之旅上海站的多数组织者们做了一次活动的回顾。经过挖掘和讨论,大家觉得我们这个团队获得成功的正向核心分别是:

  • 激情
  • 自管理的团队
  • 信任
  • 共同的价值观和目标

同时维持这次活动的能量,大家决定针对以下三个方向努力:

  • 建立公司之间交流的平台
  • 创建平台让更多的人来分享,交流
  • 建设网上社区

还是用欣赏式探寻(Appreciative Inquiry)来架构我们这次Retro

画一下我们从八月份开始启动上海之旅,到十二月会议结束的整个历程。

最早是Mike Li和我在上海南站DQ冰激凌店讨论,如何启动上海敏捷之旅,让更多的新人加入到组织者团队中。九月份启动了第一次会议,很多组织者第一次互相见面,认识。Joseph每个星期三都会给大家发短信,问“是否来参加周会,是否要订饭”。

九月份在Autodesk办公室的第一次组织者聚会。收到了Autodesk的第一笔1万元赞助。我们总结的组织者团队的四个正向核心:激情、自管理团队、信任、共同的价值观和目标。团队全家福。

十月份Mike和Stanly在地铁上讨论。小岛钻石决定赞助我们钻石。AgileTour网站正式上线(感谢Jackson张博超, 施勤文)。淘宝卖出第一张门票。Joseph还是孜孜不倦的每个星期发Meeting Minute。

十一、二月份报名数开始暴涨。由于各种原因,几个讲师不能到场,不停的发动各种关系联系讲师。提前一天到现场去装资料袋。施勤文成了我们的CFO。看到我们会场里面坐了好多人。中午很多人在上岛咖啡排队吃午饭,没有抱怨,大家十分蛋定。

Stanly等到了第一个参会者。所有的组织者、讲师来一张合影,在我们的“给例敏捷”背景板前面。Stanly发飙,写了一首诗。C hris Sims听说我们仅仅收100块门票,竟然搞出这么高质量的会议,十分吃惊。

从我们的历程中,找出正向核心。

梦想一下未来

为了实现我们的梦想,保持能量,下一步我们能做些什么,每一个想法的投入产出比又是如何?

签上自己的大名。

Share

刻意地不作为

今天在客户现场参加了一个Daily Scrum。会议结束后,团队的经理拉住我,因为她看到有一个团队成员因为对技术实现不熟悉,迟迟不能决定该拿哪个任务。而我迟迟没有发言。她觉得我应该给当时应该给她的指导,帮她选择任务。而我的回答是:

我是刻意地不作为”。而我的理由很简单:给团队一块儿空间,培养团队的自管理意识。
在团队中经常见到ScrumMaster(或者项目经理,经理等)出于种种“好心”,替团队去做事情。比如分配任务,Check任务状态,甚至帮团队去报Impediment。而这些出于好心的行为,会极大的妨碍到自管理团队的形成。往往ScrumMaster干涉太多,团队就会很自然地退缩回去,心安理得地让ScrumMaster去“帮忙”。
今天这个团队已经有自己的Working Agreement,每个成员应该用户故事自上而下(优先级顺序)认领任务,整个团队同时实现的用户故事总数不超过三个。当那个团队成员因为不能确定拿那个任务而看似僵住时,由于沉得住气,几分钟后其他的团队成员跳出来,在规则允许的情况下,帮她挑选一个适合的任务。而且哪怕没有其他人帮忙,她拿了一个不熟悉的任务,她自然也会拿着这个任务,去问其他的同事,也会促成真正的学习,长远来说,对团队建设也是有益的。
我的朋友齐微给我分享过一个她团队的故事。在她团队里面有一个团队成员,认领一个任务后,总是能够找各种各样的理由去拖延,总会影响到团队的进度。但是她同样也是刻意地不作为,一段时间后,其他的团队成员Hold不住了,他们会冲上前去,从这个“偷懒”的成员这里把任务抢过来。而这个“偷懒”的成员,已经被Out了。我很佩服齐微的“不作为”。
当然ScrumMaster和Manager并不是一点儿也不作为,要确保的是团队按照约束做事情,比如确保优先级、确保有用的项目信息充分地分享给团队,确保团队遵守既定的Work Agreement,达到Definition of Done等等。
Share

问题 vs. 方案

我们在男生厕所,都会看到类似与“向前一步,走向文明”的标语。为的是不要让小便滴到地上。这个问题说大不大,说小不小,经常会被上升到道德、全民素质。。。等的高度。一旦提升到这个高度,问题就会变得很大,而大的问题,大家都知道,很难解决。 上图是UrinalFly公司的小便器, 不同之处是在小便池的里面多了一个黑点,靠近一看,原来是一个苍蝇形状的小装饰。只是一个小小的黑点,就能让我们的厕所干净85%。方案很聪明,而且超便宜。问题很“大”,解决方案却很小。

把问题与方案分离其实贯穿整个产品开发的整个活动中,从需求到实现,再到测试。 用户故事是最流行的敏捷需求管理工具,用户故事从表面上看,尽管只是那一张小卡片,上面有一句话”As a Who, I want What, So that Why”。其实与传统的需求管理方式不单单是表面的不同,同时也是用户故事一个很大的优点,就是让我们在讨论需求的时候关注问题,而不是一下子跳到方案。而对同一个问题总是能找到多种方案(像学校考试中那样一个问题只有一个标准答案的情况在现实生活中可谓少之又少),然后去鼓励由团队提出多个解决方案(不论是业务的还是技术的),多个方案互相比较,选出最优(根据情况不同,可能是最用户体验最好、也可能最便宜、也可能实现速度最快、也可能性能最好)的。因此好的用户故事应该是关注问题的。引用Lasse Kosella的一个很不错的例子

第一种写法的问题是它“暗示”了一个方案-“铲”,而第二种写法强调了,关注的问题应该是“雪被清除掉”,和问题解决后的状态,而解决方案可能有自己去铲雪、雇人铲雪、用除雪剂。。。   同时,尽管用户故事是关于问题的,但是背后蕴含有关于可能的解决方案域(也就是所有可能解决方案的集合)的假设。PO要做的事情就是维持住这个方案域(否决任何超出方案域的方案),同时鼓励团队近一切可能提出好的方案。 还是上面那个用户故事的例子,“雇外星人来铲雪”肯定不在我们的解决方案域内。

把问题与实现分离,也是架构设计中的一个重要的原则。问题意味着不变,而实现总是要变的。面向对象技术提供了很多把问题与实现分离的方法,比如通过接口, IoC等。而如何去发现,很多情况下需要利用重构这个工具,去发现重复,然后去抽象。如果用TDD,有时候会发现几个类或者方法,你需要不断地去写类似的单元测试,而自己也不断纠结,在其他的方法的单元测试已经覆盖了这些情况,现在要另外实现一个新方法的时候,到底要不要再写一遍,很多时候,这意味着代码中有些重复的东西,该重构了。比如下面一段代码checkin

在写这个Controller类的时候,在Create/Edit/Update方法中都需要在领域模型和表现模型之间映射,尽管每一次映射不仅完全相同,但是逻辑上是做的类似的事情,在不同的模型之间映射。所以很自然地把具体映射这部分功能独立出去,八行代码(具体映射的实现, How)变成了一行代码(做映射这件事情, What),而在Controller中再也没有必要去了解如何做映射,也就是具体实现。在代码中把问题和具体实现分离,代码也会更容易维护。

TDD的另外一个好处也是让你产生具体实现方案之前有一个机会去从客户角度思考一下,解决的问题是什么?它最简单的问题是什么?

前一阵子读Gojko Azoic的“Specification by Example”,感受最深的同样也是把问题与实现分离的问题。写得好的测试与难以维护的测试一个很显著的区别就是只见流程,不见动机(Intent,也就是问题)。Gojko在书中强调了式样(Spedification)与脚本(Script)的不同。式样其实描述的是我们系统应该做什么(What),而不是怎么做(脚本, Script, How)。不幸的是我们的测试用例里面充斥着,

“在第一个页面,做什么事情;第二个页面,做什么事情,然后等待X秒钟。。。”

这样的脚本。单单看这个测试用例,读者仅仅知道自动化测试会做些什么步骤,但是不好好的看几分钟,很难去出这个测试做了一件什么事情。而具体操作的步骤是不断演变的,任何页面的变化,都会导致我们的测试失败,所以我们的自动化测试成本总是很高。而下面的测试用例却很容易读懂,也很容易维护。

Share

每周链接 #56

Retrospective
Using Innovation Games® in an Iteration Retrospective
一个Retro的分解
缓解症状

创新
伊丽莎白.吉尔伯特谈呵护创造力及减轻创作压力

精益
硝烟中的精益

领导力
在管理和领导力方面的敏捷

寓教于乐
关于小粒度频繁测试的游戏
敏捷游戏和技术

工程
Neal Ford的工程类的文章和Workshop
代码怎么能这么烂
测试驱动开发 vs. 老式单元测试
不要把设计与实现分离

其他
重复降低复杂度
我是如何评审会议投稿
TargetProcess


小胜利的威力
小规模的威力

估算
如何根据一小部分估算整个产品Backlog
看看我们的故事点与时间之间的关系
通过对速度Resampling来模拟项目

价值
估计业务价值

Share