整理敏捷开发实施框架anna.docx

整理敏捷开发实施框架anna.docx

《整理敏捷开发实施框架anna.docx》由会员分享，可在线阅读，更多相关《整理敏捷开发实施框架anna.docx（18页珍藏版）》请在冰豆网上搜索。

整理敏捷开发实施框架anna

敏捷开发实施框架

2001年，10位软件开发界著名的大师聚集在美国犹他州雪鸟滑雪圣地一起共同发布了“敏捷宣言”：

个体及交互>流程与工具、可用的软件>冗长的文档、客户协作>合同谈判、响应变化>遵循计划，敏捷开发方法才为大众所熟知。

什么是敏捷？

敏捷不是方法，而是思想，框架，目的在于“消灭一起工作效率瓶颈”，是在“不断变化”“不可预测”的环境中高效、（低耗）、（迅速）地完成“既定目标”。

【方法论的框架】【一种迭代的流程】【现有实践的集合】

【改善沟通的一种方式】【最大化生产力的一种方式】

我们对敏捷的理解和实践：

Scrum是Sprint的反复。

※首先，Scrum整体上是由连续的开发区间-Sprint构成。

Sprint开始前，召开Sprint规划会议。

此时，利害关系着在一起决定该Sprint做些什么。

※产品研发的Sprint的建议长度2到4周，偏重实现客户需求的项目型sprint，根据实践总结，sprint长度一般可长可短。

※计划会议中，一旦决定了Sprint的实施内容，也就开始了一个Sprint。

※Sprint中，每天召开DailyScrumMeeting以确认每天的进度。

利用DailyScrum和Sprint两个不同长度的Time-box进行作业。

※Sprint结束时，召开Sprint评审会议，审核成果物。

※最后，在下一个Sprint开始之前召开回顾会（RetrospectiveMeeting），讨论在下个Sprint团队应该改善的地方。

项目结束前，反复进行这样的工作。

这，就是Scrum。

今天我来谈谈我对敏捷软件开发的实践总结，说的不到之处，请大家指正。

对Scrum框架的熟悉，是实施敏捷scrum的第一步。

根据我们中心的敏捷实践，我归纳为：

三个角色，五个会议，三个产出物，两个过程控制物。

【三个角色】

敏捷项目管理中，角色分为三种，ProductOwner、ScrumMaster、团队-开发人员and架构师。

为了便于大家理解，我把敏捷研发过程隐喻为我们在拍电影。

用电影角色来形象化定义敏捷中的角色。

【ProductOwner】故事作者-从业务角度驱动项目。

•确定产品的功能，拆分用户故事story。

•根据市场价值，客户需求确定功能优先级。

（accordingtoROI）

•决定版本发布的日期和发布内容。

•每个Sprint，根据需要调整功能和优先级（原则上每个Sprint开始前调整，实际中在sprint实施过程中，也有可能调整功能和优先级）。

•接受或拒绝接受开发团队的工作成果。

•ProductOwner参与Scrumplanning。

•为产品的profitabilityoftheproduct产品盈利能力和ROI负责。

（包括市场价值，客户满意，开发成本）

其中，投资回报率（ROI）。

在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。

PO在确定优先级排列的时候，是根据ROI来确定。

【ScrumMaster】导演-Team的领导和推进者。

•保证团队资源完全可被利用并且全部是高产出的。

•保证各个角色及职责的良好协作。

•解决团队开发中的障碍。

•做为团队和外部的接口，屏蔽外界对团队成员的干扰。

•保证开发过程按计划进行，组织DailyScrum,SprintReviewandSprintPlanningmeetings。

从组织层面，都是SM组织，但是SM应该让团队“自组织”，仅指导他们到点开会，怎么样开会。

在我们实践中，DailyScrum由每个scrum“微”团队来执行。

SprintPlanningmeetings由PO来执行。

SprintReview是由团队反馈召开的信息决定，PO具体实施。

【团队】演员-交付产品并对其质量负责。

根据通信研发中心实际执行情况，我们把团队延伸为两个角色：

开发人员和架构师。

团队-开发人员：

•评估工作量（storypoint）

•拆分用户故事，定义任务（设计，界面，代码，测试，文档等）

•评估资源利用率和工作时间（在结合资源利用率情况下，评估实际完成sprint需要的时间）

•开发产品（设计，界面，代码，测试，文档等）

•确保质量（敏捷要求对团队成员技术能力有较高要求）

•改进流程（每个sprint回顾会议，改进下一个sprint的流程，没错，这是团队共同的责任！

）

•向ProductOwner演示产品功能。

团队-架构师：

•在sprint之前，按照AglieModeling的思路建立系统的架构，这个架构是和团队一起完成，并欢迎团队中每一个人为解决方案作出贡献。

•在sprint中，负责具体的重构（架构和关键业务逻辑）

•在sprint中，是一个指导者和协调者，可以确保团队不会缺少某些经验或时对某些技术感到不适而简单的拒绝一种设计方案。

也可以在团队中经常出现不同的意见。

还会带来激烈的争吵时来帮助团队打破僵局，重新和谐。

•在sprint中，和PM一起从业务价值的角度解释团队用到的技术方案的选择，所做的技术方案绝不是为了体现技术领先，而是在成熟技术和业务价值之间做平衡。

•在sprint中，story的实现不是工作重点，但是会承担部分story的实现。

在scrum团队中，“架构师”并非一个职位，尤其不是固定某人，而是倾向于在每个团队中，都确保要有能主持和协调编写架构的人，以防止队员们各自为战，符合敏捷的自组织精神的。

那实施敏捷研发和管理的组织，其他管理层在其中的角色如何定义呢？

【管理层】制片厂老板-为Scrum团队搭建良好的环境。

•为Scrum团队搭建良好的环境，以确保团队能够出色工作

•创建结构和稳定性

•必要时，也会和ScrumMaster一起重组组织结构和指导原则

【客户】制片人-为Scrum团队提出产品需求的人。

•与组织签订合同以开发产品

•在内部开发产品的公司中，批准项目预算

•一般是组织中的高级管理人员

【最终用户】观众。

•根据自己的业务知识定义产品，并告知团队自己的期望，提出请求。

很多人都可能成为最终用户。

【五个会议】

敏捷项目管理中，五个会议把整个敏捷开发模式串联起来，每个会议都代表着敏捷的一个阶段。

一、Productbacklog

该会议主要是确定产品或项目的用户故事增量。

确定具体的需求，确定做或不做。

【会议流程】：

1、用户故事的讨论和增加；

2、估算用户故事。

【会议交付物】：

最新的ＰＢ

【注意事项】：

一般召开了此会议，就不用再召开Productbacklog估算会议，新增的用户故事在本次会议上会同时做好估算。

该会议主要对疑难功能点如果转化成用户故事的一个讨论沟通会。

二、Productbacklog估算会议

做好战略规划，知道backlog中各项的大小，这是版本规划的必要输入；如果想知道团队在一个sprint中能够完成多少工作，这个数据也是必需的。

通过估算会议，团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。

估算会议也修整backlog内容，以合理方式分解backlog各项目，从而获得更深入的理解。

【会议流程】：

1.ProductOwner展示她希望得到估算的ProductBacklog条目

2.团队根据“标准故事”估算storypoint，团队听完PO讲解一个故事后，就会根据进行“标准故事”比较，估算这个故事的Point。

3.如果某个Backlog条目过大，需要放到下一个或是后续的Sprint中，团队就会将该Backlog条目划分为较小的几个Backlog条目，并对新的Backlog进行估算

4.重新估算Backlog中当前没有完成、但是可能会在接下来Sprint中要完成的条目

5.区分出下一次估算会议需要澄清的Backlog条目

【会议交付物】：

1、经过估算的，按价值和风险排列优先级的productbacklog。

2、更小的backlog。

3、需要澄清的问题，达成一致理解。

【注意事项】：

目前，对story有两种估算方法：

1、估算storypoint。

用storypoint故事点，是为了看生产率（也可理解为资源利用率，产出率等）是否有所提升才发明的。

productbacklog估算会议是根据“标准故事”估算storypoint，团队听完PO讲解一个故事后，就会根据进行“标准故事”比较，估算这个故事的Point。

故事点point是提供给你从全局上“预估”和衡量项目的大小：

每个story的point累加值。

迭代完成后回顾这次迭代的完成情况：

完成了多少个story，完成了多少个point。

估算了故事点的团队，就不再关心到底多久会出来，而是祈祷“反正故事点和上个月一样多，应该能顺利完成吧”这种祈祷，多数情况下是有效的，最后也能完成。

Sprint内的故事点一般是差不多，sprint迭代几次后，团队的生产率逐渐提高，故事点可逐渐增加。

故事点point是没有办法burn的。

需要转化成工作量。

工作量出来的时候：

story->task

sprintbacklog由领取任务的人，拆分story为task，估计绝对工作量。

工作量最大的意义在于提供一个可衡量的参数来考虑一个sprint中能否消化完这么多的point。

工作量也是衡量个体工作效率的指标。

但是敏捷前提是对个体要求有较高的工作能力的，敏捷是团队的行为，虽然敏捷也会带来一些个体工作效率提升，但只是副作用而已。

2、直接估算时间。

国内目前真正使用storypoint的企业很少，几乎没有。

因为与其去与一个标准故事比较，讨论差别，还不如直接估算工作量。

唯一遗憾的是没有办法看每个人的工作率改进。

二、Sprint计划会议

Sprint计划会议一般分为两次举行。

我们简单的命名为Sprint计划会议1和Sprint计划会议2。

Sprint计划会议1：

sprint目标，内容，story二次估算，bug，task的point估算。

两个目的：

第一个是决定哪些故事需要在这个sprint中完成，是sprint计划会议的一个主要活动。

更具体地说，就是哪些故事需要从productbacklog拷贝到sprintbacklog中。

第二个目的是分析该sprintbacklog是本次sprint会议的第二个主要目的，产品开发团队可以从该会议中详细了解最终用户的真实需要。

在会议结束，团队将会决定他们在这个sprint结果中能交付哪些东西。

补充一下，productbacklog根据我们的长期实践结果，我们定义为：

功能性需求、非功能性需求、bug三大部分。

【会议流程】：

1、功能性需求：

由PO根据估算和优先级，从PB中挑选出该sprint阶段内的backlog，在白板上提出。

2、非功能性需求：

由团队和PO共同寻找非功能性需求，在白板上提出。

3、bug：

现场bug或其他版本发现的bug。

4、由PO排列2,3,4阐述内容的优先级。

5、分析本次SprintBacklog，对1做再次估算,对2,3point估算确认。

7、PO把story的point累加值，得到本次sprint的point。

根据历史迭代的point数，确定本次sprint内容（发布的日期和发布内容）。

8、scrum团队一致认可并通过该SprintBacklog，PO确定本次sprint的目标。

【会议交付物】：

•sprint目标

•团队成员名单

•sprintbacklog

•确定好sprint演示日期

•确定好每日立会的时间地点

【注意事项】：

1、范围（scope）和重要性（importance）由产品负责人设置。

估算（estimate）由团队进行；

2、外部质量是系统用户可以感知的。

内部质量一般指用户看不到的要素。

内部质量不能当做变量而使估算时间缩减。

方法：

故事的范围缩减或调整故事的重要性。

外部质量列表

内部质量

用户可感知的，可操作的功能和性能，该功能和性能可增可减，可快可慢。

所以可理解为范围。

用户是无法感知。

是系统的质量

运行缓慢

系统设计的一致性

用户界面操作模糊

代码可读性

用户功能点比较大

代码重构

安全性，稳定性

测试

文档

评估阶段

评估对象

评估人

评估阶段

评估流程

一次估算

ProductBacklog中的story

团队

初始阶段中PB的估算会议

1、团队每个成员根据“标准故事”估算storypoint，团队听完PO讲解一个故事后，就会根据进行“标准故事”比较，估算这个故事的Point。

2、如果某个story过大，PO就要进一步拆分story，并对新的story进行估算。

3、如果团队成员的估算值相差很大，团队成员分别解释估算值；然后再重新估算。

直到大家的估算值接近某个区间。

最后由责任人决定point。

4、最后得到经过估算的、分解为更合适粒度的ProductBcaklog。

二次估算

sprintBacklog中的story，非功能性需求，bug

团队

sprint计划会议1

1、story的估算再次估算。

2、分析backlog，对延伸出来的非功能性需求的point估算。

3、对bug的point估算。

4、每个story的point累加值，得到本次sprint的point。

三次估算

story拆分后的任务

任务领取人

sprint计划会议2

1、sprintbacklog由领取任务的人对story进行任务拆分，并估计实际工作量。

2、任务接受人如果对工作量没有异议，按预估时间开始工作；如果有疑问，和任务拆分人提出时间调整意见，达成一致意见后，修改工作量。

3、详细的工作量估算出来后，如果和storypoint相差较大，和PO协商调整任务或者拆分story。

直到可在一个sprint内完成。

3、在sprint中包含多少故事由团队决定，而不是产品负责人或其他人。

4、PO可以通过调整故事优先级和故事范围（产品负责人判断出故事A中某些方面实际并不重要，所以他把A分成两个故事A1和A2，赋给它们不同的重要级别。

）来让故事进入本次sprint。

5、可利用的资源：

全身投入开发的时间基础上，考虑写文档的时间，会议，技术支持，适当的buffer或者加班时间等。

Sprint计划会议2：

功能设计会议，任务拆分，工作量和point合计调整。

2.环境影响评价的概念Sprint计划会议2以设计工作为主，产品开发团队可以为他们要实现的解决方案完成设计工作。

会议结束后，团队知道如何构建当前sprint中要开发的功能。

为了有别于传统的忽视环境价值的理论和方法，环境经济学家把环境的价值称为总经济价值（TEV），包括环境的使用价值和非使用价值两个部分。

【会议流程】：

（5）建设项目对环境影响的经济损益分析。

1、从第一个backlog条目开始。

（2）评价方法的适当性；2、确定对于客户的需求理解正确。

1.依法评价原则；3、围绕该bcaklog条目进行设计，并给予下列类似问题：

我们需要编写什么样的接口？

需要创建什么样的架构？

更新哪些表？

更新或编写哪些组件？

规划编制单位应当在报送审查的环境影响报告书中附具对公众意见采纳与不采纳情况及其理由的说明。

4、sprintbacklog由领取任务的人对story进行任务拆分task，并估计实际工作量。

task接受人如果对工作量没有异议，按预估时间开始工作；如果有疑问，和任务拆分人提出时间调整意见，达成一致意见后，修改工作量。

详细的工作量估算出来后，如果和storypoint相差较大，和PO协商调整任务或者拆分story。

直到可在一个sprint内完成。

『正确答案』B【会议交付物】：

•应用设计

（2）辨识和分析评价对象可能存在的各种危险、有害因素，分析危险、有害因素发生作用的途径及其变化规律。

•架构设计图和相关图表

表一：

项目基本情况；•一些任务

•确保团队知道应该如何完成任务（设计）

按照国家规定实行审批制的建设项目，建设单位应当在报送可行性研究报告前报批环境影响评价文件。

按照国家规定实行核准制的建设项目，建设单位应当在提交项目申请报告前报批环境影响评价文件。

按照国家规定实行备案制的建设项目，建设单位应当在办理备案手续后和开工前报批环境影响评价文件。

【注意事项】

1、敏捷对文档是轻量级的，对架构设计，接口设计，一些重要功能的设计需要有文档输出。

敏捷认为所有的中间产品，比如计划，设计，测试用例等都缺少客户价值，客户最像要的价值就是最后可运行的软件。

2、该会议上会延伸出一些非功能性需求，成为本次sprint的backlog。

3、非功能性需求超出sprint的工作量，需要再次和PO沟通变更backlog。

我们对估算会议和sprint计划会议1,2的重要内容“story的工作量估算”进行横向串联，得出以下估算流程。

二、每日站会

每日站会，收集障碍；领取或分配任务；更新任务板和燃尽图。

【会议流程】：

1、一个主持者；

2、每天早上在同样的时间和地点

3、团队成员围成一圈举行一个会议

4、在会议上每一个团队成员轮流回答：

“已完成”

“计划完成”“正在处理”“问题阻碍”（非障碍backlog，是指任务开展中需要开会讨论决议的工作，需要其他同事合作或架构师的技术协助等。

）

【会议交付物】：

•障碍backlog•最新的sprintbacklog

•最新的燃尽图

【注意事项】：

1、SM不提出问题。

2、不转变会议话题。

3、必须按时开始，迟到者不允许发言或发问。

4、不讨论深入细节。

5、不是对领导的汇报，让团队中每个人都了解你的发言。

6、不能单独讨论，自发的有序的进行发言。

7、SM不要给团队成员更新任务和燃尽图。

三、Sprint评审会议

Sprint评审会议，向最终用户展示工作成果，团队成员希望得到反馈，并以之创建或变更backlog条目。

我们这里的最终用户一般以项目经理替代客户角色。

评审会议也根据实践情况，分成了sprint末的评审和及时跟进性评审（即story的及时性验收）。

sprint末的评审：

【会议流程】：

1、SM主持会议，推进会议。

2、PO主持会议，提醒本次sprint目标，本次sprint开发的story。

3、开发团队展示新功能，并且让最终用户尝试新功能。

4、最终用户的反馈由PO记录到backlog。

【会议交付物】：

•障碍backlog输入；•来自团队或最终用户的反馈为productbacklog输入

【注意事项】：

1、不要展示不可能发布的产品增量。

2、SM不要负责展示结果。

3、团队不要针对PO展示。

及时跟进性评审：

及时跟进性评审是我们针对story的验收特别良好的敏捷实践，非会议形式。

PO和scrum团队成员点对点沟通模式。

PO对story的完成情况进行需求吻合度验证。

验证通过，进入测试环节，验证没通过，团队需要返工修改。

四、Sprint回顾会议

Sprint回顾会议也叫反思会，目的是为了吸取经验教训，改进迭代过程，重点是改进团队和组织的工作流程，Scrum团队如何在下一个Sprint中做得更好。

【会议流程】：

1、ScrumMaster首先给大家看SprintBacklog，总结这个Sprint。

2、该sprint阶段的障碍backlog（在下文中会解释什么是障碍backlog）的讨论。

Sprint期间，会不断产生障碍backlog，我们是用jira中的obstacle问题类型来进行记录和跟踪。

本次会议上就要对这个sprint阶段内的障碍backlog进行讨论和解决。

3、该sprint内工作方式，方法，过程的回顾。

与会人员轮流发言，每个人都有机会发表自己的意见：

发现什么是好的，什么是不好的。

有哪些好的做法可以启动，哪些不好的做法不能再继续下去了。

4、重大事件，重大缺陷的回顾总结。

目前我们的实践是在会议上对blocker和Critical的bug在各版本间进行clone，保持truck和个branches的版本稳定。

（这个任务仅作为我们敏捷实施在中的过渡性流程，等敏捷实践越来越成熟，这个流程会逐渐淡化到消失）

5、知识分享。

【会议交付物】：

ScrumMaster总结下一个sprint改进的要点。

我们的实践是会议的产出由项目管理工程师在下一个sprint中进行持续跟踪和改进观察；同时对需要会后完成的改进要点，记录到障碍backlog中，进行后续改进探索。

【注意事项】：

Sprint回顾会议通常是最容易被忽略的。

实际上，在敏捷框架汇总，Sprint回顾会议的重要性仅次于Sprint计划会议，是第二重要的会议。

回顾会议是Scrum团队协作进步，sprint方式方法，流程改进的最好的机会。

如果不开Sprint回顾会议，不久以后你就会发现，你的团队在不断地犯着同样的错误，sprint的脚步会永远持续不前。

【三个产出物】

工作产品

定位

内容范围

注意

ProductBacklog

产品待开发项ProductBacklog是从客户价值角度理解的产品功能列表。

它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。

•ID——统一标识符

1、如何解决问题的应该是开发团队，产品负责人只需要关注业务目标。

即PB是描述怎样使用而非怎样制造。

2、高优先级的条目应有较详尽的描述，低优先级的条目可只有一个名称。

3、不需要保证初始估算值绝对无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即，两个点的故事所花费的时间应该是四个点的故事所需的一半。

•Name——名称（摘要）

•Importance——重要性排序（客户价值优先级）

•Initialestimate——初始估算（storypoint人日）

•Howtodemo——如何做演示（验收标准）

•Notes——注解

工作产品

定位

内容范围

注意

SprintBacklog

冲刺待开发项SprintBacklog是从开发技术角度理解的迭代开发任务。

在一轮迭代中要完成的故事。

【SP中的功能性需求story】（除PB中的字段外，进入sprint的story新增以下字段）：

•story详细阐述•规划版本•story拆分成任务•执行人•具体估算工作量•开发完成时间•交付时间

1、传统的sprint只有PB中的story。

那是非常理想状态下的sprint冲刺。

根据实践，我们加入了非功能性需求和bug。

2、故事拆分成任务，避免拆分成更小的故事。

【SP中的非功能性需求task】

【bug】——现在bug或者其他版本的bug

工作产品

定位

内容范围

注意

WorkingSoftware

可工作软件WorkingSoftware是可交付的软件产品

•测试报告

done的标准是任务可以发布（编码、测试、部署、文档等），而不是仅仅编码完成。

所有done的集成，构成WorkingSoftware。

•安装手册

•配置手册

•维护手册

•用户操作手册

•安装包

【两个过程控制物】

一、燃尽图

燃尽图是敏捷开发过程中的进度管理工具图