敏捷开发中的StoryWall(进度管理)

■User Story 是什么?
User story是对软件的用户或买主有价值的功能点的描述。
1.他是用来制定计划和作为提醒的一段书面描述
2.用来充实story的细节的谈话
3.测试用例,用来表达和记录细节并且能够在story实现的时候对进行验证
每个Story都有每个Story存在的价值,编写stories的关键点在于让客户让你们的主管和经理们认可Story的价值。

■如何去编写Story
1.使用5W1H的方式去编写Story
5W1H:what, when, where, why, who, How
在编写Story的时候,用尽可能短的语言去表述清楚what,where,why就可以了
至于How,when, who则可以在planningMTG中通过和客户,领导等沟通去决定。

Story例:某某功能的内部処理を設計、実装和测试
问题点:某某功能是what?这个Story的完成基准又是什么?在这个例子中,都没有明确的说明。那么该如何去判断做什么,又如何去判断完了呢。
在优秀的软件中,每一行代码都为了完成一个或者多个功能而存在的。在Story中把真正what, where, why用最简单的方式去说明清楚吧。
設計、実装、测试、DR等等是How,是为了完成这个Story的手段。
因为Story做成提倡尽可能短,所以不要将How放入Story中。将How作为Story的一个补充说明才是上上之策。

2.一个Story必须要有一个明确的Goal
简单来说一个Story在作成完了后,必须能够判断他的Goal条件。如果Story中无法明确传达Goal条件的话,也就失去了用Story来管理进度的意义了。
至于你使用机能点还是测试点或者是成果物单位来对Story进行分解,这个是次要的,关键是每个Story要有一个明确的完成基准。

3.根据是否有明确的最终Goal分开考虑作成Story
明确最终Goal的项目中,用TopDown的方式,分解Story,每一个Story就是一个Goal,所有的小Story达成后,最终Goal也就达成,如果你的Story中有和最终Goal没有关系的小Goal,那么就把这个Story果断的去掉吧。
当没有明确最终Goal的项目中,用BottomUp的方式,把眼前能够要做的该做的先做好后,再去和客户检讨式样把。检讨以后再作成Story。如果能做到的话,就可以"拥抱变化"了。

4.不明确事项,检讨项目也需要管理
项目开发过程中,有太多的TBD项目,有太多的暧昧的地方,这就是软件开发。
这些地方也请你用Story或者其他方式将他管理起来,在早会时定期联络。不要在你的Story中出现这些不确定的内容。
如果你的Story因为某些不确定原因而无法着手的话,请果断将这个Story挂起,并及时通知ScrumMaster吧。

■如何去使用Story
1.Story需要定期维护吗
在刚开始软件开发的阶段,并不需要也没有必要把所有的Story都分好详细列出,因为软件开发中存在太多的不确定的因素。客户的需求也不是一成不变的。
刚开始只要列出一个完成开发的大致的脚本就可以了,当真正开始做之前,再把故事脚本细化为可以量化的Story。什么时候明确了需求,再去考虑为了完成需求的具体的Story。理论上在PlanningMTG的时候把近1~2周的计划列出来,进行相对的工作量估算后,就开始冲刺。如果能够这样的话,团队的效率是最高的。
所以敏捷开发中提倡的就是一边开发一边去作Story。

2.StoryPoint如何确定
根据书上所说,先选出一个大小适中的Story作为模板,将Point分为1,3,5,8,13等相对数值来标示一个作业的工作量。每个Story最好能够在3天之内完成。
我觉得相对于花时间去想去决定Point,还不如把时间花在项目本身上,Point只是一个工作量的标示罢了。每个项目都有每个项目的特殊性,Point也好,对一个Story使用百分比也好,只要能够将进度实现可视化就可以了。

3.进度的自我管理
用Story管理也好,用白板管理进度也好,用其他的进度管理方式也好。都只是进度管理的方法而已。真正清楚进度的人并不是项目主管,项目经理,也不是客户,应该是担当该要件的人。当你发现进度提前或者落后的时候,就主动想好原因对策以后,找ScrumMaster沟通吧。世界上没有完美的项目进度计划,项目中每个人的进度情况构成了一个项目的进度情况。使用好Story去管理进度,而不要依赖于Story去管理进度。

4.Story仅仅只是为了进度管理吗?不是。
进度管理只是他一部分的作用,利用Story不仅仅是进度管理,Story也是要件担当者和项目关系者(主管,项目经理,测试员,客户)之间的一个沟通模板。
利用好这个沟通模板,才能更好的挖掘出客户的潜在需求,才能更好的将自己的成果频繁主动的展示给你的项目经理。拿着你做好的Story主动和他们去沟通吧。
敏捷开发提倡频繁的沟通,如果没有良好而频繁的沟通,Story的作用效果也就大打折扣了。

结束语:如果一个要件是一部电影的话,担当要件的人就是总导演,Story就是为了完成电影的一个个镜头。在设计软件之前,请先设计好你的Story把。一个个短短的镜头就构成了一部电影。做一个优秀的导演,从先设计好一个个短短的镜头(Story)开始。

你可能感兴趣的:(项目管理)