敏捷开发实施框架

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

敏捷开发实施框架

2001年,10位软件开发界著名的大师聚集在美国犹他州雪鸟滑雪圣地一起共同发布了“敏捷宣言”:个体及交互>流程与工具、可用的软件>冗长的文档、客户协作>合同谈判、响应变化>遵循计划,敏捷开发方法才为大众所熟知。

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

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

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

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

Scrum是Sprint的反复。

※首先,Scrum整体上是由连续的开发区间 - Sprint构成。Sprint开始前,召开Sprint 规划会议。此时,利害关系着在一起决定该Sprint做些什么。

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

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

※Sprint中,每天召开Daily Scrum Meeting以确认每天的进度。利用Daily Scrum和Sprint 两个不同长度的Time-box进行作业。

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

※最后,在下一个Sprint开始之前召开回顾会(Retrospective Meeting),讨论在下个Sprint团队应该改善的地方。

项目结束前,反复进行这样的工作。这,就是Scrum。

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

对Scrum框架的熟悉,是实施敏捷scrum的第一步。根据我们中心的敏捷实践,我归纳为:三个角色,五个会议,三个产出物,两个过程控制物。

【三个角色】

敏捷项目管理中,角色分为三种,Product Owner、Scrum Master、团队-开发人员and 架构师。为了便于大家理解,我把敏捷研发过程隐喻为我们在拍电影。用电影角色来形象化定义敏捷中的角色。

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

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

•根据市场价值,客户需求确定功能优先级。(according to ROI)

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

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

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

• Product Owner参与Scrum planning。

•为产品的profitability of the product 产品盈利能力和ROI负责。(包括市场价值,客户满意,开发成本)

其中,投资回报率(ROI)。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。PO在确定优先级排列的时候,是根据ROI来确定。

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

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

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

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

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

•保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning meetings。

从组织层面,都是SM组织,但是SM应该让团队“自组织”,仅指导他们到点开会,怎么样开会。在我们实践中,Daily Scrum由每个scrum“微”团队来执行。Sprint Planning meetings由PO来执行。Sprint Review是由团队反馈召开的信息决定,PO具体实施。

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

根据通信研发中心实际执行情况,我们把团队延伸为两个角色:开发人员和架构师。

团队-开发人员:

•评估工作量(story point)

•拆分用户故事,定义任务(设计,界面,代码,测试,文档等)

•评估资源利用率和工作时间(在结合资源利用率情况下,评估实际完成sprint需要的时间)•开发产品(设计,界面,代码,测试,文档等)

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

•改进流程(每个sprint回顾会议,改进下一个sprint的流程,没错,这是团队共同的责任!)

•向Product Owner演示产品功能。

团队-架构师:

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

•在sprint中,负责具体的重构(架构和关键业务逻辑)

•在sprint中,是一个指导者和协调者,可以确保团队不会缺少某些经验或时对某些技术感到不适而简单的拒绝一种设计方案。也可以在团队中经常出现不同的意见。还会带来激烈的争吵时来帮助团队打破僵局,重新和谐。

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

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

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

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

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

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

•创建结构和稳定性

•必要时,也会和Scrum Master一起重组组织结构和指导原则

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

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

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

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

【最终用户】观众。

•根据自己的业务知识定义产品,并告知团队自己的期望,提出请求。很多人都可能成为最终用户。

【五个会议】

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

一、 Product backlog

该会议主要是确定产品或项目的用户故事增量。确定具体的需求,确定做或不做。

【会议流程】:

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

2、估算用户故事。

【会议交付物】:

最新的PB

【注意事项】:

相关文档
最新文档