敏捷开发中的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)开始。