敏捷开发实施框架

1、敏捷开发实施框架2001年，10位软件开发界著名的大师聚集在美国犹他州雪鸟滑雪圣地一起共同发布了“敏捷宣言”：个体及交互>流程与工具、可用的软件>冗长的文档、客户协作>合同谈判、响应变化>遵循计划，敏捷开发方法才为大众所熟知。什么是敏捷？敏捷不是方法，而是思想，框架，目的在于“消灭一起工作效率瓶颈”，是在“不断变化”“不可预测”的环境中高效、（低耗）、（迅速）地完成“既定目标”。【方法论的框架】【一种迭代的流程】【现有实践的集合】【改善沟通的一种方式】【最大化生产力的一种方式】我们对敏捷的理解和实践：Scrum是Sprint的反复。 首先，Scrum整体上是由连续的开发

2、区间 - Sprint构成。Sprint开始前，召开Sprint规划会议。此时，利害关系着在一起决定该Sprint做些什么。产品研发的Sprint的建议长度2到4周，偏重实现客户需求的项目型sprint，根据实践总结，sprint长度一般可长可短。计划会议中，一旦决定了Sprint的实施内容，也就开始了一个Sprint。 Sprint中，每天召开Daily Scrum Meeting以确认每天的进度。利用Daily Scrum和Sprint两个不同长度的Time-box进行作业。 Sprint结束时，召开Sprint评审会议，审核成果物。最后，在下一个Sprint开始之前召开回顾会（Retro

3、spective Meeting)，讨论在下个Sprint团队应该改善的地方。项目结束前，反复进行这样的工作。这，就是Scrum。今天我来谈谈我对敏捷软件开发的实践总结，说的不到之处，请大家指正。对Scrum框架的熟悉，是实施敏捷scrum的第一步。根据我们中心的敏捷实践，我归纳为：三个角色，五个会议，三个产出物，两个过程控制物。【三个角色】敏捷项目管理中，角色分为三种，Product Owner、Scrum Master、团队-开发人员and架构师。为了便于大家理解，我把敏捷研发过程隐喻为我们在拍电影。用电影角色来形象化定义敏捷中的角色。【Product Owner】故事作者 - 从业务角度

4、驱动项目。 确定产品的功能，拆分用户故事story。 根据市场价值，客户需求确定功能优先级。(according to ROI) 决定版本发布的日期和发布内容。 每个Sprint，根据需要调整功能和优先级（原则上每个Sprint开始前调整，实际中在sprint实施过程中，也有可能调整功能和优先级）。 接受或拒绝接受开发团队的工作成果。 Product Owner参与Scrum planning。 为产品的profitability of the product 产品盈利能力和ROI负责。（包括市场价值，客户满意，开发成本）其中，投资回报率（ROI）。在敏捷开发过程中，最具价值的功能总是被优先开

5、发，这样能给客户带来最大的投资回报率。PO在确定优先级排列的时候，是根据ROI来确定。【Scrum Master】导演 - Team的领导和推进者。 保证团队资源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。 解决团队开发中的障碍。 做为团队和外部的接口，屏蔽外界对团队成员的干扰。保证开发过程按计划进行，组织 Daily Scrum, Sprint Review and Sprint Planning meetings。从组织层面，都是SM组织，但是SM应该让团队“自组织”，仅指导他们到点开会，怎么样开会。在我们实践中，Daily Scrum由每个scrum“微”团队来执行。

6、Sprint Planning meetings由PO来执行。Sprint Review是由团队反馈召开的信息决定，PO具体实施。【团队】演员 - 交付产品并对其质量负责。根据通信研发中心实际执行情况，我们把团队延伸为两个角色：开发人员和架构师。团队-开发人员：评估工作量（story point）拆分用户故事，定义任务（设计，界面，代码，测试，文档等）评估资源利用率和工作时间（在结合资源利用率情况下，评估实际完成sprint需要的时间）开发产品（设计，界面，代码，测试，文档等）确保质量（敏捷要求对团队成员技术能力有较高要求）改进流程（每个sprint回顾会议，改进下一个sprint的流程，没错

7、，这是团队共同的责任！） 向Product Owner演示产品功能。团队-架构师：在sprint之前，按照Aglie Modeling的思路建立系统的架构，这个架构是和团队一起完成，并欢迎团队中每一个人为解决方案作出贡献。在sprint中，负责具体的重构（架构和关键业务逻辑）在sprint中，是一个指导者和协调者，可以确保团队不会缺少某些经验或时对某些技术感到不适而简单的拒绝一种设计方案。也可以在团队中经常出现不同的意见。还会带来激烈的争吵时来帮助团队打破僵局，重新和谐。在sprint中，和PM一起从业务价值的角度解释团队用到的技术方案的选择，所做的技术方案绝不是为了体现技术领先，而是在成熟技

8、术和业务价值之间做平衡。在sprint中，story的实现不是工作重点，但是会承担部分story的实现。在scrum团队中，“架构师”并非一个职位，尤其不是固定某人，而是倾向于在每个团队中，都确保要有能主持和协调编写架构的人，以防止队员们各自为战，符合敏捷的自组织精神的。那实施敏捷研发和管理的组织，其他管理层在其中的角色如何定义呢？【管理层】制片厂老板 - 为Scrum团队搭建良好的环境。 为Scrum团队搭建良好的环境，以确保团队能够出色工作 创建结构和稳定性 必要时，也会和Scrum Master一起重组组织结构和指导原则【客户】制片人 - 为Scrum团队提出产品需求的人。 与组织签订合

9、同以开发产品 在内部开发产品的公司中，批准项目预算 一般是组织中的高级管理人员【最终用户】观众。 根据自己的业务知识定义产品，并告知团队自己的期望，提出请求。很多人都可能成为最终用户。【五个会议】敏捷项目管理中，五个会议把整个敏捷开发模式串联起来，每个会议都代表着敏捷的一个阶段。一、 Product backlog该会议主要是确定产品或项目的用户故事增量。确定具体的需求，确定做或不做。【会议流程】：1、用户故事的讨论和增加； 2、估算用户故事。【会议交付物】：最新的【注意事项】：一般召开了此会议，就不用再召开Product backlog估算会议，新增的用户故事在本次会议上会同时做好估算。该会

10、议主要对疑难功能点如果转化成 用户故事的一个讨论沟通会。二、 Product backlog估算会议做好战略规划，知道backlog中各项的大小，这是版本规划的必要输入；如果想知道团队在一个sprint中能够完成多少工作，这个数据也是必需的。通过估算会议，团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。估算会议也修整backlog内容，以合理方式分解backlog各项目，从而获得更深入的理解。【会议流程】：1. Product Owner展示她希望得到估算的Product Backlog条目 2. 团队根据“标准故事”估算story point，团队听完PO讲解一个故事后，就会根据进行

11、“标准故事”比较，估算这个故事的Point。 3. 如果某个Backlog条目过大，需要放到下一个或是后续的Sprint中，团队就会将该Backlog条目划分为较小的几个Backlog条目，并对新的Backlog进行估算 4. 重新估算Backlog中当前没有完成、但是可能会在接下来Sprint中要完成的条目 5. 区分出下一次估算会议需要澄清的Backlog条目 【会议交付物】：1、经过估算的，按价值和风险排列优先级的product backlog。 2、更小的backlog。 3、需要澄清的问题，达成一致理解。【注意事项】：目前，对story有两种估算方法：1、估算story point。

12、用story point故事点，是为了看生产率（也可理解为资源利用率，产出率等）是否有所提升才发明的。product backlog估算会议是根据“标准故事”估算story point，团队听完PO讲解一个故事后，就会根据进行“标准故事”比较，估算这个故事的Point。故事点point是提供给你从全局上“预估”和衡量项目的大小：每个story的point累加值。迭代完成后回顾这次迭代的完成情况：完成了多少个story ，完成了多少个point。估算了故事点的团队，就不再关心到底多久会出来，而是祈祷“反正故事点和上个月一样多，应该能顺利完成吧”这种祈祷，多数情况下是有效的，最后也能完成。Spri

13、nt内的故事点一般是差不多，sprint迭代几次后，团队的生产率逐渐提高，故事点可逐渐增加。故事点point是没有办法burn的。需要转化成工作量。工作量出来的时候：story->task sprint backlog由领取任务的人，拆分story为task，估计绝对工作量。工作量最大的意义在于提供一个可衡量的参数来考虑一个sprint中能否消化完这么多的point。工作量也是衡量个体工作效率的指标。但是敏捷前提是对个体要求有较高的工作能力的，敏捷是团队的行为，虽然敏捷也会带来一些个体工作效率提升，但只是副作用而已。2、直接估算时间。国内目前真正使用story point的企业很少，几乎

14、没有。因为与其去与一个标准故事比较，讨论差别，还不如直接估算工作量。唯一遗憾的是没有办法看每个人的工作率改进。二、Sprint计划会议Sprint计划会议一般分为两次举行。我们简单的命名为Sprint计划会议1和Sprint计划会议2。Sprint计划会议1： sprint目标，内容，story二次估算，bug，task的point估算。 两个目的：第一个是决定哪些故事需要在这个sprint中完成，是sprint 计划会议的一个主要活动。更具体地说，就是哪些故事需要从product backlog拷贝到sprint backlog中。第二个目的是分析该sprint backlog是本

15、次sprint会议的第二个主要目的，产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议结束，团队将会决定他们在这个sprint结果中能交付哪些东西。补充一下，product backlog根据我们的长期实践结果，我们定义为：功能性需求、非功能性需求、bug三大部分。 【会议流程】：1、功能性需求：由PO根据估算和优先级，从PB中挑选出该sprint阶段内的backlog，在白板上提出。 2、非功能性需求：由团队和PO共同寻找非功能性需求，在白板上提出。3、bug：现场bug或其他版本发现的bug。4、由PO排列2,3,4阐述内容的优先级。5、分析本次Sprint Backlog，对1

16、做再次估算,对2,3point估算确认。7、PO把story的point累加值，得到本次sprint的point。根据历史迭代的point数，确定本次sprint内容（发布的日期和发布内容）。8、scrum团队一致认可并通过该Sprint Backlog，PO确定本次sprint的目标。【会议交付物】：sprint目标团队成员名单sprint backlog确定好sprint演示日期确定好每日立会的时间地点【注意事项】：1、范围（scope）和重要性（importance）由产品负责人设置。估算（estimate）由团队进行；2、外部质量是系统用户可以感知的。内部质量一般指用户看不到的要素。内

17、部质量不能当做变量而使估算时间缩减。方法：故事的范围缩减或调整故事的重要性。外部质量列表内部质量3、在sprint中包含多少故事由团队决定，而不是产品负责人或其他人。 4、PO可以通过调整故事优先级和故事范围（产品负责人判断出故事A中某些方面实际并不重要，所以他把A分成两个故事A1和A2，赋给它们不同的重要级别。）来让故事进入本次sprint。 5、可利用的资源：全身投入开发的时间基础上，考虑写文档的时间，会议，技术支持，适当的buffer或者加班时间等。Sprint计划会议2：功能设计会议，任务拆分，工作量和point合计调整。Sprint计划会议2以设计工作为主，产品开发团队可以为他们要实

18、现的解决方案完成设计工作。会议结束后，团队知道如何构建当前sprint中要开发的功能。【会议流程】： 1、从第一个backlog条目开始。 2、确定对于客户的需求理解正确。 3、围绕该bcaklog条目进行设计，并给予下列类似问题：我们需要编写什么样的接口？需要创建什么样的架构？更新哪些表？更新或编写哪些组件？ 4、sprint backlog由领取任务的人对story进行任务拆分task，并估计实际工作量。task接受人如果对工作量没有异议，按预估时间开始工作；如果有疑问，和任务拆分人提出时间调整意见，达成一致意见后，修改工作量。详细的工作量估算出来后，如果和story point相差较大，

19、和PO协商调整任务或者拆分story。直到可在一个sprint内完成。【会议交付物】：应用设计 架构设计图和相关图表 一些任务 确保团队知道应该如何完成任务（设计）【注意事项】1、 敏捷对文档是轻量级的，对架构设计，接口设计，一些重要功能的设计需要有文档输出。 敏捷认为所有的中间产品，比如计划，设计，测试用例等都缺少客户价值，客户最像要的价值就是最后可运行的软件。 2、该会议上会延伸出一些非功能性需求，成为本次sprint的backlog。 3、非功能性需求超出sprint的工作量，需要再次和PO沟通变更backlog。我们对估算会议和sprint计划会议1,2的重要内容“story的工作量估

20、算”进行横向串联，得出以下估算流程。二、每日站会每日站会，收集障碍；领取或分配任务；更新任务板和燃尽图。【会议流程】：1、一个主持者； 2、每天早上在同样的时间和地点 3、团队成员围成一圈举行一个会议 4、在会议上每一个团队成员轮流回答： “已完成”“计划完成” “正在处理” “问题阻碍”（非障碍backlog，是指任务开展中需要开会讨论决议的工作，需要其他同事合作或架构师的技术协助等。）【会议交付物】：障碍backlog 最新的sprint backlog最新的燃尽图【注意事项】：1、SM不提出问题。2、不转变会议话题。3、必须按时开始，迟到者不允许发言或发问。4、不讨论深入细节。5、不是对

21、领导的汇报，让团队中每个人都了解你的发言。6、不能单独讨论，自发的有序的进行发言。 7、SM不要给团队成员更新任务和燃尽图。三、Sprint评审会议Sprint评审会议，向最终用户展示工作成果，团队成员希望得到反馈，并以之创建或变更backlog条目。我们这里的最终用户一般以项目经理替代客户角色。评审会议也根据实践情况，分成了sprint末的评审和及时跟进性评审（即story的及时性验收）。sprint末的评审：【会议流程】：1、SM主持会议，推进会议。 2、PO主持会议，提醒本次sprint目标，本次sprint开发的story。 3、开发团队展示新功能，并且让最终用户尝试新功能。 4、最终

22、用户的反馈由PO记录到backlog。【会议交付物】：障碍backlog输入； 来自团队或最终用户的反馈为product backlog输入【注意事项】：1、不要展示不可能发布的产品增量。 2、SM不要负责展示结果。 3、团队不要针对PO展示。及时跟进性评审：及时跟进性评审是我们针对story的验收特别良好的敏捷实践，非会议形式。PO和scrum团队成员点对点沟通模式。PO对story的完成情况进行需求吻合度验证。验证通过，进入测试环节，验证没通过，团队需要返工修改。四、Sprint回顾会议Sprint回顾会议也叫反思会，目的是为了吸取经验教训，改进迭代过程，重点是改进团队和组织的工作流程，S

23、crum 团队如何在下一个Sprint 中做得更好。【会议流程】：1、 Scrum Master 首先给大家看Sprint Backlog，总结这个Sprint。2、 该sprint阶段的障碍backlog（在下文中会解释什么是障碍backlog）的讨论。Sprint期间，会不断产生障碍backlog，我们是用jira中的obstacle问题类型来进行记录和跟踪。本次会议上就要对这个sprint阶段内的障碍backlog进行讨论和解决。3、 该sprint内工作方式，方法，过程的回顾。与会人员轮流发言，每个人都有机会发表自己的意见：发现什么是好的，什么是不好的。有哪些好的做法可以启动，哪些不好

24、的做法不能再继续下去了。 4、 重大事件，重大缺陷的回顾总结。目前我们的实践是在会议上对blocker和Critical的bug在各版本间进行clone，保持truck和个branches的版本稳定。（这个任务仅作为我们敏捷实施在中的过渡性流程，等敏捷实践越来越成熟，这个流程会逐渐淡化到消失）5、 知识分享。【会议交付物】：Scrum Master总结下一个sprint改进的要点。我们的实践是会议的产出由项目管理工程师在下一个sprint中进行持续跟踪和改进观察；同时对需要会后完成的改进要点，记录到障碍backlog中，进行后续改进探索。【注意事项】：Sprint 回顾会议通常是最容易被忽略的

25、。实际上，在敏捷框架汇总，Sprint 回顾会议的重要性仅次于Sprint 计划会议，是第二重要的会议。回顾会议是Scrum 团队协作进步，sprint方式方法，流程改进的最好的机会。如果不开Sprint 回顾会议，不久以后你就会发现，你的团队在不断地犯着同样的错误，sprint的脚步会永远持续不前。【三个产出物】Initial estimate初始估算（story point人日） 1、传统的sprint只有PB中的story。那是非常理想状态下的sprint冲刺。根据实践，我们加入了非功能性需求和bug。 2、故事拆分成任务，避免拆分成更小的故事。 【bug】现在bug或者其他版本的bug【两个过程控制物】一、燃尽图燃尽图是敏捷开发过程中的进度管理工具图。展示剩余待完成工作与时间的关系，每日立会后更新燃尽图。未完成工作（Backlog）标识在纵坐标轴上，时间标识在横坐标轴上，可以用来协助预测项目所有的工作何时能完成，剩余多少工作量。未完成的工作可以从任务个数Issure Burndown Chart和任务工作量Hour Burndown Chart两个角度去展示。 【发布燃尽图】【 sprint燃尽图】【个人燃尽图】注意事项：1、 燃尽图要求对sprint内的任务状态及时更新。2、 对spr