|
摘要：
需求澄清后，SE把所有的故事卡贴到故事墙上，等待开发人员的开发。故事墙的模板为： 分析 ： 需求澄清完成后，SE把所有的故事卡都贴到分析阶段 等待开发： 开发人员和SE确认了需求，明确了做什么以及怎么做以后，把故事卡从分析阶段移到等待开发 开发中 ： 开发人员一次只开发一张故事卡，把相应开发的那张卡移植到开发中 阻塞 ： 如果开发过程中，由于配合的原因，导致故事卡无法继续走下去，则把该卡移动到阻塞阶段 开发完成 ：如果开发完成，并向SE SHOW CASE以后，开发人员吧故事卡移植到等待测试 等待测试 ：测试人员看到等待测试中有卡以后，对... 阅读全文
posted @ 2011-06-12 16:15 zhangweia 阅读(715) 评论(0) 推荐(0) 编辑
摘要：
SE整理完一个迭代的需求以后，进入下一个流程需求澄清，需求澄清的主要目的是给开发人员澄清需求，确认开发点。 需求澄清的一般流程为： 1. SE给开发人员讲解需求点 2. 开发人员评论需求点是否合理，完善 3. 开发人员大致描叙实现该需求点的难点 4. 所有人员对该需求点进行评点，如果评的点不统一，则要评点多和少的人员依次讲解他们评该点的原因，讲解完成后在进行一次评点，选择大多数人的点为该需求的点 5. 把评的点和优先级写入故事卡 阅读全文
posted @ 2011-06-12 11:08 zhangweia 阅读(1000) 评论(0) 推荐(0) 编辑
摘要：
迭代需求的整理是敏捷开发的第一步，也是敏捷开发很重要的一步，在这一步中我们需要把客户的业务需求按照优先级的顺序，整理成为一个个的迭代。然后把一个个的迭代拆成一个个可验收的故事卡。 在此需要说说什么是故事卡，故事卡和业务需求之间的关系。故事卡是一个个独立的，可验收的功能，一个业务需求可以拆分为多个故事卡。比如：我们常见的账号管理需求，需要对账号进行增、删，改、查。因为添加、修改、删除、查询都是一个个可单独验收的场景，我们可以把账号管理需求拆分为四个故事卡。因此把需求拆分为故事卡的原则是： 1.故事卡是可以独立验收的场景 2.故事卡包含的点数... 阅读全文
posted @ 2011-06-12 10:11 zhangweia 阅读(495) 评论(0) 推荐(0) 编辑
摘要：
敏捷是一柄双刃剑，用的好能极大的提升开发效率，适应需求的变化！用的不好则会导致项目的混乱。现在很多公司都说自己在用敏捷开发，很多程序员也说自己懂敏捷开发！简单的认为敏捷就是站立会议，就是迭代的开发，到最后敏捷变成了混乱，然后开始说敏捷的不好等等。其实他们都只是表面上的敏捷，而没有真正的理解敏捷的含义。敏捷做为一种新的编程方法论，是有他一套完成的方法学的。 敏捷开发提倡迭代开发，小版本的发布和测试，首先我们来看看迭代的开发流程和附加要求，然后我们对怎样做好每个流程就行详细的设计。 因为敏捷开发提倡一个迭代80%以上的时间都在编程，几乎没有设计的阶段，因为我们必须保证我们的代码的质量。因此在整个. 阅读全文
posted @ 2011-06-12 07:45 zhangweia 阅读(605) 评论(0) 推荐(0) 编辑 |
||
