|
一、根据发布目标分析需求，把需求分析成独立的故事，初步的分析可以是粗略的，随着需求的不断深入刻意对故事进行整合或者切割。项目管理者联盟文章
要注意的是分析出来的需求尽量在发布目标的范围之内，超出发布目标的需求应该尽量避免过深分析。项目管理培训
所谓的发布目标是确定了这个版本可以让用户满意的条件。
故事模式：做为(用户角色)，我可以(做什么)，以便(业务价值)。后面的业务价值在比较简单或者大家都比较明确的时候刻意不需要注明。项目管理者联盟
当前团队实践推行方法：项目管理培训
第一阶段，这个分析工作开始由PM进行收集、整理和分析。项目管理者联盟
第二阶段，当大家都为用户故事的方式接受以后，采用需求讨论的方式来明确和分析用户故事。项目管理者联盟文章
二、对分析的故事进行相对估计，估计出来的故事点是对用户故事和复杂度的无单位估计值，使用的数值大小本身没有绝对意义，只有相对于其他故事规模的相对意义。talent.mypm.net
比如，用户登录这个用户故事的估计值是2，那么做为同等开发规模的用户推出，这个用户故事的估计只也应该是2。项目管理论坛
当前团队实践推行方法：项目管理论坛
第一阶段，这个估计的工作暂时由PM来负责完成，但是由于一个人的估计肯定会有偏差，所以在估计完成之后需要进行调查来进行修正。项目管理者联盟
第二阶段，用估计扑克会议来统一的对用户故事进行估计，当主持人拿出一个新的用户故事之后，大家给出自己对这个故事使用扑克打分，然后取出平均值，对差异较大的估计值要给出解释，来消除对用户故事的错误理解。估计扑克会议的实践不超过1个小时。项目管理者联盟
三、准备产品调查，对用户故事进行功能存在，和功能缺失性的产品调查，然后根据调查结果对用户故事进行划分，划分成3类：基本需求，线性需求，非线性需求。项目管理论坛
此外还有反对的需求、存在疑问的需求、无所谓的需求3种类型的需求，这些需求将根据进一步的发展进行确认。项目管理者联盟
当前团队的实践推行办法：项目管理者联盟
第一阶段，由PM发出调查问卷在参与到项目的开发团队、测试团队、技术支持团队来进行调查，然后汇总答案根据存在问题和缺失问题的答案，对用户故事进行定性。blog.mypm.net
第二阶段，由PM发出调查问卷扩展到相关的用户群体中进行调查，然后汇总答案根据存在问题和缺失问题的答案，对用户故事进行定性。项目管理者联盟
四、确定发布规划，首先要确定的是迭代周期的长度，以周为单位，然后估计出每个迭代周期团队的速度。然后可以从用户故事池中选择出合适的用户故事来填充到第一次和第二次的迭代周期中。其余的暂时可以先不用填充，随着每次迭代周期的完成来对发布计划进行更新。最后根据估计的速度和需要开发的故事来确定需要几个迭代周期，并最终有几个迭代周期来确定需要开发的时间周期。发布计划可以以功能来驱动进行，也可以以日期来驱动进行。blog.mypm.net
发布规划的特点，以月做为时间范围，规划对象是用户故事，估计的单位是故事点。项目管理者联盟
当前团队的实践推行办法：项目管理者联盟
第一阶段，使用1周做为迭代周期，开始时团队速度使用估计的方式做出简单估计，根据每个周期结束后的团队速度再进行发布计划的调成。迭代周期内用户故事的完成暂时以开发完成做为标准。service.mypm.net
第二阶段，使用2周做为迭代周期，可以使用原有的历史速度做为团队速度，多出的一周时间做为测试修复时间，迭代周期内用户故事的完成以测试完成，完整的功能提交做为标准，并在开发过程中熟练使用单元测试来进行确保功能的完整完成。项目管理论坛
五、确定迭代规划，根据填充到迭代周期内的用户故事来分解成工作任务，工作任务包括设计工作，不同层次的开发工作，调试工作和测试工作等等具体的任务，然后对任务进行估计，这时候估计的单位以理想工作小时做为单位。比如，设计需要两个人小时，开发持久层需要1个人小时，调试持久层需要半个人小时，开发业务层需要2个人小时，调试中间层需要1个小时等。bbs.mypm.net
然后根据每个故事的人小时和这个迭代周期内参与的人数，以及每个人所能参与的实际有效时间(注意有效时间约为每天6小时，需要考虑到会议，讨论，头脑休息等非理想工作时间)来判断这个迭代周期的填充是否足够，如果不够则再加入一个用户故事，如果超出则移出一个用户故事到下一个迭代周期中。
迭代规划的特点，以周做为时间范围，规划对象是工作任务，估计的单位是理想小时。PgMp.mypm.net
|
