敏捷开发过程
敏捷开发流程的8个步骤
敏捷开发流程的8个步骤敏捷开发是一种以迭代、循序渐进的方式进行软件开发的方法论，它强调团队合作、快速响应变化和持续交付价值。
在敏捷开发过程中，有以下8个主要步骤。
1. 需求收集与分析在敏捷开发中，需求是一个动态的过程，不断地收集、分析和细化。
团队与客户紧密合作，明确项目的愿景和目标，并将其转化为用户故事或需求项。
通过不断的讨论和反馈，团队可以更好地理解客户需求，并将其转化为可执行的任务。
2. 规划与估算在敏捷开发中，规划是一个迭代的过程。
团队根据客户需求和项目目标，制定短期的开发计划，确定每个迭代的工作范围和目标。
同时，团队也需要对工作量进行估算，以便更好地安排资源和时间。
3. 设计与开发在敏捷开发中，设计和开发是并行进行的。
团队利用迭代周期进行软件设计和编码，采用简单而优雅的解决方案。
团队成员经常进行代码审查和知识分享，以确保代码的质量和可维护性。
4. 测试与验证在敏捷开发中，测试是一个持续且重要的过程。
团队进行单元测试、集成测试和系统测试，以确保软件的质量和功能完整性。
同时，团队也需要与客户进行验证，确保软件满足客户的需求和预期。
5. 交付与部署在敏捷开发中，交付和部署是一个可重复且自动化的过程。
团队使用持续集成和持续交付的工具和方法，将软件快速交付给客户。
同时，团队也需要确保软件能够顺利地部署和运行。
6. 反馈与优化敏捷开发强调不断地学习和改进。
团队与客户保持密切的沟通，收集用户反馈和需求变更。
团队通过迭代回顾和持续改进的方式，优化软件的功能和性能。
7. 沟通与协作在敏捷开发中，沟通和协作是非常重要的。
团队成员之间需要密切合作，共同解决问题和完成任务。
团队与客户之间也需要建立良好的沟通渠道，保持及时的反馈和信息共享。
8. 迭代与持续交付敏捷开发是一个持续迭代的过程。
团队通过多次迭代的方式，逐步完善软件，持续交付价值。
团队通过反馈和学习，不断优化和改进软件的质量和功能。
总结敏捷开发是一种灵活、高效的软件开发方法论。
敏捷开发过程中如何开发高质量的软件
敏捷开发过程中如何开发高质量的软件敏捷开发是一种迭代、协作的开发方法论，旨在通过快速迭代和持续反馈，更好地满足客户需求。
在敏捷开发过程中，如何开发高质量的软件是一个重要的问题。
下面将介绍几个关键的因素。
1.测试驱动开发（TDD）测试驱动开发是一种先写测试用例，再写代码的开发方法。
在开发过程中，首先根据需求编写测试用例，然后编写代码使之通过测试。
这种方法可以帮助开发者思考和细化需求，并确保代码的可测试性。
通过频繁执行测试，可以及早发现和修复潜在的问题，提高软件质量。
2.持续集成（CI）持续集成是一种频繁将代码集成到共享代码库中，并通过自动化构建和测试来验证代码的更改是否会导致问题的开发方法。
通过持续集成，可以及时发现和解决代码集成问题，避免大规模代码冲突导致的问题。
持续集成还可以通过自动化测试套件的运行，及时发现代码质量问题，保证软件的健壮性。
3.代码质量管理在敏捷开发中，通过持续集成和自动化测试可以发现代码质量问题，但需要进一步加强代码质量管理。
例如，可以使用静态代码分析工具（如SonarQube）对代码进行检查，发现潜在的代码问题。
同时，在进行代码走查和代码审查时，可以发现代码中的潜在问题，并及时对其进行修复。
4.正确的设计和架构在敏捷开发过程中，正确的设计和架构对于实现高质量软件至关重要。
开发者应该遵循设计原则和模式，将系统分解为模块化的组件，避免代码的耦合和重复。
同时，开发者还应该考虑系统的可扩展性、可维护性和性能等方面的因素，以确保软件的高质量。
5.用户参与和持续反馈在敏捷开发过程中，用户的参与和持续反馈对于开发高质量软件至关重要。
通过与用户的沟通和反馈，开发者可以更好地理解用户需求和期望，并及时进行调整和优化。
敏捷开发方法论中的迭代和增量开发也提供了实现用户参与和持续反馈的机制。
通过频繁发布版本，可以快速接收用户的反馈并进行相应的改进，提高软件的用户满意度和质量。
总结起来，敏捷开发过程中开发高质量软件的关键因素包括测试驱动开发、持续集成、代码质量管理、正确的设计和架构以及用户参与和持续反馈。
软件敏捷开发流程
软件敏捷开发流程首先，软件敏捷开发流程的第一步是需求分析和产品规划。
在这一阶段，开发团队需要与客户充分沟通，了解客户的需求和期望，确定产品的功能和特性。
团队成员需要明确各自的角色和责任，制定产品规划和项目计划，并确保团队成员对项目目标的一致理解。
接下来是迭代开发阶段。
敏捷开发流程采用迭代开发的方式，将整个项目划分为若干个迭代周期，每个迭代周期通常持续2-4周。
在每个迭代周期内，开发团队根据客户需求和产品规划，完成软件功能的开发和测试，并及时向客户展示和反馈产品的进展。
客户可以在每个迭代周期内提出修改和调整，开发团队可以根据客户反馈及时调整开发方向，保证产品的灵活性和及时性。
此外，敏捷开发流程还强调团队协作和交付价值。
在整个开发过程中，团队成员之间需要密切合作，保持高效的沟通和协调。
团队成员需要时刻关注产品的交付价值，确保每个迭代周期都能交付高质量的软件产品。
同时，团队需要不断地进行自我反思和总结，不断优化和改进开发流程和方法，以提高团队的工作效率和产品质量。
最后，软件敏捷开发流程还注重客户参与和反馈。
在整个开发过程中，客户是开发团队的重要参与者，他们需要积极参与产品的规划和设计，及时提出需求和反馈。
开发团队需要及时响应客户的需求和反馈，确保产品能够满足客户的期望和要求。
综上所述，软件敏捷开发流程是一种灵活、高效的软件开发方法，它强调团队协作、客户参与和交付价值。
通过合理的需求分析和产品规划、迭代开发和客户参与，敏捷开发流程能够保证软件产品的高质量和及时交付，满足客户需求，适应市场变化，是当前软件开发领域的一种主流开发方法。
敏捷开发流程(自己总结)
敏捷开发的相关简介敏捷定义Scrum是一个轻量级的软件开发方法Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。
在这个框架中，整个开发周期包括若干个小的迭代周期，每个小的迭代周期称为一个Sprint，每个Sprint的建议长度2到4周。
在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。
Scrum的开发团队总是先开发的是对客户具有较高价值的需求。
在每个Sprint 中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。
Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。
在每个迭代结束时，Scrum 团队将交付潜在可交付的产品增量。
敏捷的原则个体与交互胜过过程与工具可以工作的软件胜过面面俱到的文档客户协作胜过合同谈判响应变化胜过遵循计划这四句价值观用语句表达就是：自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件。
胜过与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，最后交付需求。
《敏捷宣言》12条原则1.最优先的目标是通过尽早地、持续地交付有价值的软件来满足客户。
2.欢迎需求变化，甚至在开发后期。
敏捷过程控制、利用变化帮助客户取得竞争优势。
3.频繁交付可用的软件，间隔从两周到两个月，偏爱更短的时间尺度。
4.在整个项目中业务人员和开发人员必须每天在一起工作。
5.以积极主动的员工为核心建立项目，给予他们所需的环境和支持，信任他们能够完成工作。
6.在开发团队内外传递信息最有效率和效果的方法是面对面的交流。
7.可用的软件是进展的主要度量指标。
8.敏捷过程提倡可持续发展。
敏捷开发具体流程
敏捷开发具体流程嗨，朋友！你要是想知道敏捷开发是个啥流程，那你可算找对人了。
我就像一个在敏捷开发战场上摸爬滚打多年的战士，今天就把这其中的门道给你好好唠唠。
咱先得有个产品愿景啊。
这就好比咱们要盖一座大楼，那得先有个大楼建成之后的美好蓝图在心里。
比如说我们团队要开发一个全新的手机APP，那这个APP最终要达成啥样的功能，要给用户啥样的体验，这就是产品愿景。
老板或者产品负责人就像那个领航员，“嘿，大家听着啊，咱们这个APP得是那种用户一打开就觉得超酷，操作特别简单又功能强大的东西。
”团队成员们听了，眼睛里就开始冒星星，充满了期待。
接下来就是创建产品待办事项列表。
这就像是给大楼准备建筑材料的清单。
产品负责人会和各个相关的人员，像开发人员、测试人员、市场人员等坐在一起。
开发人员可能会说：“哎，要实现这个功能，后端得有这样那样的接口。
”测试人员也会插一句：“那这个功能得有明确的测试标准才行。
”市场人员则想着：“这功能得符合用户需求，还得能吸引用户眼球呢。
”大家七嘴八舌地讨论，把所有要做的事情都列出来，从大的功能模块到小的细节优化，都在这个清单里。
有了这个清单，就到了冲刺计划会议。
这时候就像一场紧张又刺激的战前部署。
团队成员们聚在一起，看着产品待办事项列表，就像看着一堆宝藏等着去挖掘。
大家开始挑选在这个冲刺周期里要完成的任务。
开发人员会根据自己的能力和经验，说：“我觉得我这个周期能搞定这个功能模块和那个小优化。
”测试人员也不含糊：“那我这边就负责把这些新功能的测试给包了。
”这就像在战场上，每个士兵都认领自己的任务一样。
然后呢，开发过程就开始啦。
开发人员就像一群勤劳的小蜜蜂，嗡嗡嗡地开始干活。
他们会把大的任务分解成一个个小的任务，就像把一块大蛋糕切成小块一样。
在这个过程中，每天都会有个简短的站会。
大家站成一圈，就像一群朋友在聊天。
开发人员会说：“我昨天完成了这个小功能的一半，今天打算把它彻底搞定，不过可能会遇到点小麻烦，需要和数据库那边再对接一下。
敏捷开发流程的8个步骤
敏捷开发流程的8个步骤
1、目标制定，目标对齐：通过市场调研、业务思路、风险评估制定公司规划和目标，根据这一目标产生所有部门的目标并实现对齐；
2、产品规划：产品研发部门根据目标制定产品关键路线图，这个路线图中分布着不同的产品特性和其完成时间；
3、组织产品待办列表：产品规划产生的需求、客户需求、市场人员收集到的缺陷等将组成产品待办列表；
4、需求梳理：然后产品负责人(Product Ower)对这个列表进行梳理，并在需求梳理会(Backlog Grooming Meeting)讲解具体每一个需求，团队成员根据需求的复杂程度评估每个任务的工作量，输出本次迭代的待办事项列表，完成优先级排序等工作；
5、迭代规划：通过Sprint计划会，明确要执行的工作、冲刺目标等，
6、迭代开发：期间会进行每日站会、性能测试、CodeReview、Demo、测试等工作；
7、Sprint评审：由每个任务的负责人演示其完整的工作，由PO确定Sprint目标是否完成，版本什么时候对外发布，新增bug的紧急程度等等。
8、开回顾会议：回顾会议由Scrum团队检视自身在过去的Sprint的表现，包括人、关系、过程、工具等，思考在下一个Sprint中怎么样可以表现得更好，更高效，怎么样可以和团队合作地更愉快。
云效敏捷开发流程
云效敏捷开发流程随着云计算技术的迅速发展以及互联网行业的兴起，敏捷开发方法逐渐成为许多企业和团队选择的开发模式。
而在这个过程中，云效作为一款专业的敏捷开发工具，为开发团队提供了更加便捷高效的开发流程。
本文将详细介绍云效敏捷开发流程的具体步骤，希望能帮助更多团队实施敏捷开发，并取得成功。
一、需求规划阶段需求规划是敏捷开发中至关重要的一个环节，它决定了整个项目的成败。
在云效敏捷开发流程中，需求规划阶段主要包括以下几个步骤：1.明确项目目标：团队成员要明确项目的整体目标和愿景，确保所有人都对项目的方向有清晰的认识。
2.分解需求：将项目的整体需求分解为可执行的小任务，每个任务都应该具有明确的目标和可测量的价值。
3.优先排序：根据任务的紧急程度和重要性对任务进行优先排序，确保团队按照优先级进行工作。
4.迭代规划：制定项目的迭代计划，明确每个迭代的目标和周期，确保团队的工作重心不断调整和优化。
二、迭代开发阶段在需求规划阶段确定了项目的迭代计划之后，团队就可以开始进入迭代开发阶段。
在云效敏捷开发流程中，迭代开发阶段主要包括以下几个步骤：1.任务分配：根据迭代计划将任务分配给各个团队成员，确保每个人都有明确的任务和目标。
2.持续集成：团队成员在开发过程中需要保持持续集成的节奏，不断将代码合并到主干分支，确保代码质量和稳定性。
3.自动化测试：使用自动化测试工具对代码进行全面测试，确保代码的质量和功能完整性。
4.持续交付：将代码交付给测试和运维团队进行验证和部署，确保代码能够及时地交付给用户。
5.迭代回顾：在迭代结束后进行回顾会议，总结过程中的经验教训，为下一轮迭代做准备。
三、持续优化阶段持续优化是敏捷开发中一个非常重要的环节，它可以帮助团队不断改进和提升工作效率。
在云效敏捷开发流程中，持续优化阶段主要包括以下几个步骤：1.团队协作：团队成员需要保持良好的沟通和协作，共同解决问题和挑战，确保项目稳步推进。
2.持续学习：团队成员需要不断学习和探索新的技术和方法，提高自身的能力和水平。
敏捷开发详细流程
敏捷开发详细流程一、引言敏捷开发是一种以迭代、循序渐进的方式进行软件开发的方法论。
它强调团队合作、快速反馈和适应性，以实现高质量的软件产品交付。
本文将介绍敏捷开发的详细流程，包括需求分析、计划、设计、开发、测试和交付等各个阶段。
二、需求分析阶段在敏捷开发中，需求分析是一个关键的阶段。
团队与客户密切合作，明确产品的功能和特性，并将其记录为用户故事。
用户故事是对用户需求的简短描述，包含一个角色、一个目标和一些条件。
团队通过与客户的沟通来完善用户故事，并根据重要性和优先级对其进行排序。
三、计划阶段在计划阶段，团队制定一个迭代计划，确定在每个迭代中要完成的用户故事。
团队根据故事点（Story Points）来估算工作量，并根据团队的速度和可用资源来制定计划。
此外，还需要确定每个迭代的时间周期和迭代目标。
四、设计阶段在设计阶段，团队根据用户故事和需求分析，设计软件架构和系统接口。
团队采用迭代方式进行设计，每个迭代都会有一个可工作的原型。
团队成员之间进行密切合作，确保设计满足用户需求，并具备可扩展性和可维护性。
五、开发阶段在开发阶段，团队按照迭代计划进行开发工作。
每个迭代都有一个明确的目标和交付物。
团队采用迭代和增量的方式进行开发，每个迭代都会生成一个可工作的软件版本。
团队成员之间进行紧密协作，及时解决问题和调整计划。
六、测试阶段在测试阶段，团队对软件进行全面的测试，包括单元测试、集成测试和系统测试等。
测试团队与开发团队密切合作，及时发现和修复缺陷。
测试用例是根据用户故事和需求编写的，以确保软件满足功能和性能要求。
七、交付阶段在交付阶段，团队将软件交付给客户，并进行部署和安装。
团队与客户一起测试软件，并进行用户培训和支持。
团队还会收集用户的反馈和建议，以改进产品和提高用户满意度。
八、迭代循环敏捷开发是一个迭代循环的过程，每个迭代都会生成一个可工作的软件版本。
团队根据用户反馈和需求变更，不断优化和调整产品。
迭代周期通常为2至4周，以保证快速交付和快速反馈。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Scrum 敏捷开发过程实战产品级，大团队的敏捷实战方法与传统灌输理念的培训不同，此实战培训中不只包含“按客户价值进行优先级排序”“利用自组织团队发挥主观能动性”等含糊的指导性思想，更在每个阶段均介绍一种或多种直接可以使用的方法来完成落地。
按照实际项目的开发顺序，培训分为三个环节，其主要内容如下：● 需求结构化与需求描述（主要受众为产品负责人Product Owner 、团队骨干）⏹将产品愿景转换为可实现的业务需求； ⏹将高层业务需求分解为具备层级结构的需求树； ⏹编写用户故事，面向用户使用场景而非产品功能描述单条需求； ● 版本规划与迭代计划（主要受众为产品负责人、Scrum Master ，团队骨干）⏹在宏观层面上，确认整个产品中所有子系统的优先级，并将其顺序计划到版本和迭代中； ⏹ 在微观层面上，利用Scrum 计划会估算每个迭代中任务的工作量；● 日常活动与团队建设（主要受众为Scrum Master ，团队成员）⏹日常活动中，利用每日立会、故事板、看板跟进开发进度； ⏹ 团队建设中，利用自组织团队、松结对编程等方法建立师徒制度，在实际工作中培养队员； 需求结构化需求描述 版本规划迭代计划日常活动 团队建设⏹在大型、跨职能团队研发时的团队结构与工作方式●附：敏捷设计与工程实践（仅出现于3天培训中，主要受众为团队成员及技术管理者）⏹如果从用户故事经过简单设计得到代码结构⏹如何利用用户故事来产生、管理测试用例⏹如何利用用户故事来管理变更、缺陷和客户反馈课程将围绕每个小组实际工作中各自产品或项目的自身需求展开，通过对其进行结构化、用户故事化、用户建模、模拟计划会估算、设定验收标准等，从而演练Scrum各个环节所需的技能。
知识及案例讲解约占70%，实际练习约占30%。
注：本大纲中以一个易于理解的电子商务系统的研发为例，实际应用时可应用于银行、电信、政府、电子商务、互联网社区娱乐、仪器仪表等各种主流行业。
×××××××××××××××××××××××××第一天××××××××××××××××××××××××××××××概述本阶段培训通过简短介绍，让学员大致了解敏捷开发的历史及其尝试解决的问题。
●敏捷开发尝试解决的问题●Scrum及其历史⏹产品负责人 Product Owner⏹产品负责人团队⏹产品负责人的职责现场演练：分组并推选Product Owner第一阶段：需求结构化与需求描述本阶段培训旨在从头到尾打通需求，即从感性的产品愿景分解到可供开发的具体需求条目。
传统敏捷开发使用“条目化”的方法来表达需求。
但具体分解和描述需求的方法停留在“每个故事交付一个客户价值”“从客户价值角度描述需求”等非常含糊、难以落地的层面上。
这导致分析所得的需求个体差别很大，难以作为大型、长期产品研发的正式工程文档。
本课程引入了QUML作为分界用户故事的基础，通过三层需求完成从产品愿景到可开发任务的分解：*配图中的三层分解流程见下文分步描述。
三层需求分别为业务愿景（左上图），业务操作（左下图中的方框，即史诗故事），业务数据（右侧三张图中的椭圆，即用户故事）。
这就解决了传统敏捷开发中存在的以下问题：1.最初的产品愿景与割裂的用户故事之间缺少必然联系2.大量用户故事之间缺少清晰的结构3.用户故事颗粒度大小不一此外，这种体系下建立起来的“用户故事树”（需求树）还能：1.直接分配到开发任务中2.直接生成代码结构3.直接用于结构化管理变更、增强、重构、缺陷等4.直接与测试用例匹配而为一人年的工作量进行这种需求分析，只需要1小时左右。
第一步：业务愿景——利用“角色-业务图”来支撑产品愿景愿景（Vision）是用户对产品的核心期望。
培训中使用“角色-业务图”（简称RB图）来表达和落实愿景。
比如在配图中：“购物子系统”核心愿景是“建立一种有保障的网上购物方式”；图中使用“确认收货-转账”的第三方监管业务实现。
这样软件开发人员就能得到确切的技术方案，而不是面对描述非常虚的愿景；而技术方案实现后，又能支撑愿景。
有了愿景，产品就不会简单停留在“能用”的状态，而是要积极增加可以实现愿景的功能。
现场演练与指导：建立角色业务图（20分钟）案例分享：RB图详细规则与最佳实践第二步：业务数据——利用“实体-关系图”发掘业务数据此内容将客户愿景转化为“对某些的业务数据的操作”，从而逐渐进入开发人员可理解的范畴；同时业务数据还是早期功能点估算的核心元素。
具体分析工具是实体-关系图（简称ER图），而业务数据对应其中的实体（图中方框）。
实体-关系图（教学过程中进行了简化）中分析了实体及其依赖关系，通过适当定义，不但可以保障不会遗漏实体，甚至能直接协助进行早期估算和部分设计工作。
重要！在敏捷开发中，我们将业务数据作为史诗故事进行开发。
比如在配图中，所有实体（5个矩形）均包含一组“增删改查”或类似的操作（就是第三步中的用户故事），由此可知此图包含１６５人天左右的工作量／３张数据库主表和２张关系表／５组增删改查操作页面。
现场演练与指导：建立实体关系图（30分钟）案例分享：ER图详细规则与最佳实践第三步：业务操作——利用“用例-流程图”分析业务操作借助精益需求建模方法（“用例-流程图”，一种由User Case和状态图结合演进产生的新图形，简称UCF图），找到一个最小的、完备的业务操作集合，作为一次交付所能发布的最新功能集合。
在精益开发中，这个集合称之为MVP， Minimum Viable Product最小可用产品。
用例-流程图的“一致性”非常好，即两个不同的分析人员针对同一需求的分析结果，无论用例的数量、名称、乃至排列顺序都惊人地相似。
重要！在敏捷开发中，我们将业务操作作为用户故事。
右图是QUML中的“增查查改删”模板中，通过将需求分解为增加-查看所有-查看单个-修改-删除五层，并将不同角色执行的操作放在其正下方（共有操作放在中间），需求分析人员可以迅速而无遗漏地获得所有用户故事。
同时，图中由业务逻辑连接的各个业务操作（即椭圆形区域）形成一个MVP，多一个操作则是多余的，少一个则不能完整交付。
这对于每个迭代能持续交付至关重要。
现场演练与指导：建立用例流程图（60分钟）案例分享：UCF图详细规则与最佳实践第四步：需求树——建立结构化的需求传统用户故事组织方法均呈现“列表结构”，在用户故事数量庞大时（注：每人年大约能完成用户故事50个，外加子故事50～200个），很难看到整个需求的全貌。
培训中，会借助业务愿景-业务数据-业务操作的层次，对需求条目进行结构化表达，形成一棵有层次的需求树。
如图，看似是一个很普通的“增删改查表”，但图中的第二至四级目录实际上来自于之前的业务愿景-业务数据-业务操作。
这样就很容易从之前的图形化需求形成树形的需求树，其不同层次对应不同尺度的用户故事。
注：很多业界的敏捷开发工具如Jira都引入了层次化用户故事，但均没有提供层次定义和可操作的分解方法。
本培训采用Word作为演示工具，也可对应到具体工具中。
×××××××××××××××××××××××××第二天××××××××××××××××××××××××××××××第五步：用户故事——面向用户价值的需求描述方式很多软件虽然交付了功能，却不是客户想要的。
比如，微博这类的大型系统的管理员，是否会有一个“查看所有用户”这样的功能来管理几亿个用户？如果没有，他怎么知道有哪些用户？如果有，如何避免海量用户造成的信息爆炸？敏捷开发引入了一种面向客户价值而非产品功能的需求描述方式，将功能放在具体的使用环境中讨论，从而能为客户制作出符合其价值的产品。
现场演练与指导：编写自己的用户故事（30分钟）案例分享：文字游戏还是价值挖掘挖掘第六步：用户建模——购买决策者/主要使用者“今年过节不收礼，收礼就收脑白金”。
尽管多数收礼者（主要使用者）并不知道脑白金到底包含何种成分，服用后到底有哪些好处，但是确有无数的送礼者（购买决策者）选择购买。
本内容介绍如何区分购买决策者和主要使用者，并面向核心用户编写用户故事。
现场演练与指导：建立自己的用户模型（30分钟）案例分享：一款年收入12亿元的网络游戏对“所有用户”的理解第二阶段：版本规划与迭代计划本阶段以第一阶段生成的各层次用户故事为输入，进行宏观的版本规划和微观的迭代计划。
传统敏捷开发缺少版本规划的具体实施方法，“按客户价值优先级进行排序”听起来有道理但却难以实施。
尤其是在初期无法获得全部用户故事的情况下，优先级排序非常困难。
本培训中的方法可以：1.在开发的初期即可提供颗粒度可控的高层需求（史诗故事）进行排序；2.产品经理根据业界统计数据即可进行版本规划；3.在版本规划的同时自动完成工作量规划，从而准确安排迭代的数量；在每个迭代的计划会上通过“敏捷扑克估算”，借助集体智慧解决个体问题：1.迅速找到最快的解决办法；2.发现高手与新手的差距，并通过讨论弥补差距；3.以10分钟代价提前发现上千行代码的浪费；第一步：版本规划——项目早期的量化分层规划方法版本规划涉及到立项时的战略性规划、迭代间的发布规划、随时可能发生的产品升级规划等不同层次。
培训中会建立三级规划方法与之对应，分别是业务愿景规划、业务数据规划和业务操作规划。
由于业务数据的定义兼容FPA（功能点分析）中ILF（内部逻辑文件）的定义，因此每个业务数据无需知道细节即可按业界数据2人月计算（精确数值为35人天）。