《用户故事与敏捷方法》阅读笔记01

                                                                                    用户故事与敏捷方法第一章是对用户故事的概览。
      首先第一个问题用户故事是什么?用户故事描述了对用户、系统或软件购买者有价值的功能。用户故事由三个方面组成,包括1 .一份书面的故事描述,用来做计划和作为提示。2.有关故事的对话,用于具体化故事细节。3.测试,用于表达和编档故事细节且可用于确定故事何时完成。
      然后第二个问题细节,故事的细节可以用另外的用户故事来描述,多个小故事远远胜于一个庞大的故事。书上将大的故事成为史诗故事,那些史诗故事可以分为多个小故事。例如将“用户可以搜索工作”分为1.用户通过地区、薪水范围、职位、公司名和发布日期来搜索。2.用户可以查看搜索结果中的每个工作的信息。3.用户可以查看发布工作的公司的详细信息。但是故事并不一定要分解到可以覆盖到每个细节。一些细节可以让开发团队和客户讨论,换句话说要让这些细节变得重要时才被讨论。
      第三个问题是用户期望,要将用户期望记录下来在纸质卡片的背面或者是电子文档的空白处。让开发人员了解客户的期望。客户团队是因为找不到专职人员排列工作的优先级,以及回到开发人员的问题而建立的,它理应包括满足用户需求的所有人,其中有测试人员,产品经理,实际用户,交互设计师。
      第四个问题使用故事的过程是怎么样的?在传统的面向瀑布的模型中只有在开始和结束时参与。对于故事驱动的项目而言,客户和用户在整个过程都参与,他们在编写用户故事时承担非常活跃的角色,尤其是在团队极限编程时。编写用户故事的过程最好从考虑系统的用户类别开始,客户团队最好包括这些实际的客户类别,如果不能,则可以使用用户角色建模代替。然后开始写故事的初稿,初稿一般是在故事编写工作坊中写的,(用户故事可以在项目生命周期的任何时候写),大家充分发挥想象来写故事。写完故事初稿后,客户团队和开发人员一起选择迭代的长度。每轮迭代客户团队高度参与故事和测试。确定迭代长度后,开发人员会估计每轮迭代做的事情,然后估计发布计划。在迭代时把最高优先级的故事放在第一堆,然后依次进行,直到项目完成。(每轮迭代之前客户团队可以修订计划,用实际速率来代替估计速率,并进行修正。)
     第五个问题规划发布和迭代,客户和开发人员都要参与发布和迭代,排列故事优先级时,应该坚持组织利益最大化,同时要听从技术人员的意见。
     第六个问题验收测试。验收测试是用来验证用户故事是否符合客户团队的期望。测试应该尽早在迭代中编写,这样客户团队的假设和预期会更早与开发人员沟通。
通过第一章的阅读,我认识到,开发的过程用户参与非常的重要,用户故事在整个开发过程中起着主导作用,同时开发人员还要对用户的故事提出技术上的修正和指导。客户团队和开发人员在开发过程中不断修正方向最终才能完成任务。

posted @ 2016-10-16 17:50  键盘已坏  阅读(142)  评论(0编辑  收藏  举报