存档

文章标签 ‘敏捷’

iOS平台应用开发的敏捷设计流程

2011年12月8日 没有评论

手机游戏开发者布莱恩·罗宾斯(Brian Robbins)在文中介绍了开发iPhone游戏所需注意的事项及流程,目的在于为开发商指点迷本文翻译自《Computer Arts》中对专注于iPhone和iPad应用开发的设计师Sarah Parmenter的访谈录,希望对iPhone应用开发的朋友能有所帮助。

我们曾介绍过iPhone应用界面设计指南,本文翻译自《Computer Arts》中对专注于iPhone和iPad应用开发的设计师Sarah Parmenter的访谈录,希望对iPhone应用开发的朋友能有所帮助。

以下为全部译文:

对设计师来说,iPhone和iPad是全新的平台。相比图形和网站设计的经验积累,在iPhone和iPad上的设计进化还都处于萌芽期。

在这里,Sarah跟大家分享了简单明了的火车时刻表软件设计流程和基本原则,可能对你自己的设计项目有所启发。为了简化过程,我们假设获取火车运行数据的API是现成的。

1.首先,要确定你的创意还没有人做过。如果你发现已经有类似的App,那你需要比它做的更好,有一些独特的优化设计。最好的调查方式是到iTunes Store上搜索已有的iPad程序。

2.当有了创意,你还需要有个明确的定位,它会在后续的设计过程中决定App的设计要点。App定位可以通过苹果的人机界面指南(Human Interface Guidelines)图来确定。

苹果的人机界面指南

距离图中坐标原点位置越远的App,特点越明显,越需要精美易用的界面设计,让他们与其他竞争者明显区分开来。在这个案例中,我们把App定位在原点位置,即简单使用的辅助工具。

3.确定App定位后,接下来需要聚焦App的核心功能。在团队合作设计时,这一点尤其重要。团队在提出各种功能需求时,很容易陷入哪些功能要包含在第一个版本中的争论。Apple把这个过程叫设计ADS(Application Definition Statement),或者叫设计精简的ADS。

设计ADS

4.走到这一步,很多人会认为对App的设计已经想的很清楚,可以直接开始设计图形界面甚至编码了。实际上,前面的过程,仅仅设计的导入阶段。我们接下来要做的,是产品草图设计。一般我们用纸和笔来画,它们是最简单,学习成本最低的工具。按照我们的设计经验,勾画出用户需要用到的界面,包括像按钮之类的界面交互元素;筛选出核心用户最常用的,最适合移动应用场景的功能。

产品草图设计

5.我们要设计的是辅助工具软件,通常,它只需要主界面,和一个在背面显示相关信息的辅助界面,它通过信息按钮触发后翻转显示。如果你设计的是其他App,可能还需要更多的界面。重点是要设计界面与界面之间的切换方式,这一点在设计交付给开发人员时会显得尤其重要。我们把这个过程叫做App功能穿越(App Functionality Walkthrough)。

6.现在,开始App的低保真原型设计。重点是不要陷入过多的细节,低保真只是把你纸面上的草图数字化,便于在电脑上持续的改进。所以,尽量使用黑白,粗糙的线条和图形来制作低保真,别在细节上纠结,浪费时间。

草图数字化

7.低保真原型完成后,开始设计注重细节和精度的高保真原型。我使用PhotoShop,你可以选用自己熟悉的其他工具。一般,我会为iPad设置尺寸为1024X768的画布,然后根据低保真原型进行细节设计。

8.当我们设计App的主界面时,显示列车时刻表是设计的重点。它不需要包含所有功能,应着重显示列车到达时间,出发时间,列出延误或者取消等必要信息。

9.鉴于Apple提倡有质感,有仿真度的图形界面,我们让App的界面设计尽量接近用户熟悉的火车站时刻表。在配色上,使用灰色,黑色,亮黄和红色,配合一些个性化的图标来表示迟到和取消状态。

App的界面设计尽量接近用户熟悉的火车站时刻表

10.很重要的一点是,App所展现的信息,必须简洁明了,没有多余的文字。所以,在界面设计上,我们没有引入任何华丽的图形或者其他的信息来干扰用户,让他们能一眼就看明白App的用途。在数据条目之间使用间隔色,用醒目的字体显示到达和出发时间,这些都是很好的设计体现。主界面背后的相关信息界面,使用Apple的标准界面即可,为用户提供搜索列车后加入关注的功能。

11.我使用了很多细微的渐变和一些材质,重要的是,确保所有的信息都一目了然,不隐晦,不误导用户。

确保所有的信息都一目了然

12.现在可以开始考虑icon的设计。这将决定App在App Store上的辨识度。你可以从简单的轮廓设计开始设计,先把核心创意表现出来。

icon的设计

13.除非有必要,你的icon最好不要包含文字,尽量使用跟你的App图形界面一致的材质和渐变。你如果想给用户呈现高质量的UI设计,别忘了把icon设计成29×29,72×72,和512×512三种尺寸。

App图形界面一致

14.如果你自己不开发App的功能,还需要把清晰的设计指南交付给开发人员。我会把界面和描述集中到一张大图,并尽可能的把所有可遇见的情况都给开发人员描述清楚。

把清晰的设计指南交付给开发人员

15.最后,我们把低保真原型,所有的图形界面设计图(一般是PSD)和图标打包在一起,做上清楚的标注,发送给开发人员。有时候,你可能还需要对PSD进行切图,存成PNG,方便开发人员直接使用。

PSD进行切图

关于Sarah Parmenter

Sarah Parmenter

英国艾塞克斯(英国英格兰东南部的郡)Youknowwho设计工作室的创始人,Sarah Parmenter专注于网站,iPhone和iPad应用的设计。设计工作室创立于2003年。Sarah Parmenter在访谈中介绍了她在设计列车时刻表App时的流程和设计原则。

译后感

Sarah所讲述的设计流程,跟我们设计传统web软件的流程没有太大差别,都是基于统一的设计方法论。但是,App Store开创了一个全新的软件生态系统,它不仅改写了软件的交付和消费方式,也对软件的设计产生着显著的影响。

App Store上成功的应用,绝大部分都是面向个人的软件,它们功能简单(相对于传统的B/S或者C/S软件来说),注重满足用户的核心需求,设计上极力追求完美,我把他们叫做微应用。由于这个微字,要求这些应用的设计过程要比传统的UCD过程更敏捷;同时,微字带来了App Store超过30万的应用(截至2010年12月),也造就了赢家通吃的生存法则。

成功的App设计,要求在上线第一天就能够吸引用户。如果你上市的第一个月没有进入排行榜,那马上会在第二个月死亡。 微应用把Release soon, Release often法则打破了,它执行的是苹果法则,Release awesome, Release incredible。

Sarah的设计流程,可以归纳为以下的步骤:

市场定位 —》App定义(ADS) —》概念草图 —》低保真原型 —》高保真原型 —》设计交付物说明和整理 —》外包开发

在这个流程中,并没有传统UCD方法论中强调的用户分析,场景分析,信息架构设计等环节,他们已经变成基本原则,融入到具体的原型设计过程中去了。为什么会这样?还是因为微应用的特性决定的。软件足够小,不需要也不可能承受冗长的基础分析和设计过程所带来的成本,它需要的是更敏捷的设计流程,用尽量完美的设计,来满足用户的特定需求。

同样的,敏捷设计流程,逼迫设计团队必须裁剪需求,才能更好的适应赢家通吃法则。一个小软件的失败,损失的可能只是4周的工作时间,这并不是什么大不了。你完成可以通过另一个新产品来获得成功。

这篇访谈给我最大的启发,就在于敏捷设计对于App设计的重要性,还有老外在面对微应用时,对于设计流程的坚持。

分类: 9其他 标签: ,

敏捷开发实践 拥抱变化的产品开发流程

2011年5月10日 没有评论

随着Agile敏捷开发的流行,越来越多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法,一直实践到现在,并取得不错的成果,包括:产品功能更加符合市场和业务人员的需求,开发效率获得提高。本文从实践的角度介绍笔者所在团队的产品敏捷开发过程和作者的敏捷开发体会。

敏捷开发体会

实施敏捷开发近两年来,我对在产品开发中应用敏捷方法有着深刻的体会。首先说下产品背景。我参与的产品是面向行业的产品,在全世界都有客户,有10年历史,和一百多个基于不同版本的客户,我们的团队完全负责产品的未来发展方向、发布计划、架构、设计、开发进度、测试、客户支持等。在这样一个面向全球的产品和自主的团队环境中进行敏捷开发体会尤其深刻。

1) 注重概念和架构设计,而轻详细设计

敏捷开发中,注重概念和架构设计,而轻详细设计。这里的概念设计,可以看成是为什么要做这个产品或模块,强调的是产品的路线规划、市场趋势、客户价值、技术趋势等。架构设计,可以看成从整体上看,概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。详细设计,则是具体的设计和做法、API接口等。

一个产品,特别是面向行业的产品,概念设计和架构设计非常重要,需要考虑行业未来的发展方向,产品在市场中横向和纵向的比较,技术的发展方向,和每个模块的投入和收益的比例等,这样才能尽可能保证产品沿着正确的方向前进。在产品中新增或删除一个模块需要非常谨慎,因为一旦新增模块被客户使用,以后就很难在产品中去掉这个模块。还需要考虑产品各个版本之间的兼容性,以及客户的升级迁移。所以,在开始正式开发之前,通过概念设计和架构设计,梳理思路是非常必要的。

2) SWOT分析

以前在做项目时,大多是从技术角度来考虑哪一些功能模块需要做,哪一些功能模块先做,而没有一个系统化的分析方法。造成的结果是有一些功能模块投入很多资源,却并不一定是客户最想要的。

在敏捷开发中,更加注重客户需求。如果对产品进行SWOT分析,就能选出付出最小工作量,但能获得最大价值的模块。

SWOT分析阶段会在概念设计和架构设计之后进行,输入是概念设计和架构设计,输出是模块的重要度和需要的时间。这样按照性价比可以进行排序,选出最能符合市场的模块。

一款产品哪个模块重要,哪个先做,需要花多少资源和时间投入,花这么多时间和资源的模块是否在客户心中有相应的重要程度等,这些都是由这款产品的市场策略来决定。所有产品都是为了市场和赢利为目的,Agile方法更好地帮助企业实现了这一点。

3) 业务和客户驱动,而非技术驱动

这点说是体会,也可以说是教训。在我们的产品开发过程中,在某一新版本中重新设计了老版本的某一个重要模块,而引发了几个问题:一是,新版本的模块和老版本模块的兼容性问题,导致老版本客户无法平滑的迁移到新版本;二是,新版本的改进是纯技术方面的重新实现,不管对客户而言,还是对内部的架构而言,都没有明显好处;最后导致的结果是我们花了很多资源和人力去重新实现,但是在最后由于种种考虑还是废弃了重新实现的模块,依然沿用老模块。

在产品的敏捷开发中,虽说拥抱变化,但不盲目变化。产品的改动需要经过概念设计、架构设计以及SWOT分析后,三思而后行。敏捷开发中也强调”在整个项目开发期间,业务人员和开发人员必须天天都在一起工作”,确保技术人员能够开发出客户需要的产品。

4) 时刻考虑版本兼容性

敏捷开发,废除了过多冗余的文档和繁杂的设计,强调拥抱变化。但作为产品,敏捷开发不意味着盲目地去变化。

当设计变动、API接口重构、配置文件变更时,要时刻考虑产品的架构、规划路线图,老版本的兼容性,及迁移平滑性。否则,随着版本的增多,必将面对着大量的维护工作。

5) 轻文档,但非无文档

敏捷开发强调沟通的重要性,而轻冗余文档。但敏捷开发并不意味着无文档。在敏捷开发过程中,适量的文档还是很有帮助,有助于整理思路,加快沟通和讨论。

我们产品中的文档包括:概念设计文档、架构图、当前版本要实现的功能列表,以及SWOT分析。

这些文档在每个产品版本开始之前会有产生,在每个迭代的过程中根据业务人员和市场的反馈也会有一些变更。通过我们实践证明,这对产品的思路、沟通讨论都非常有帮助。

而且这些文档,大多是几页PPT,书写和维护工作都很小。

共3页: 1 2[3]

内容导航

第 1 页:敏捷开发的体会 第 2 页:敏捷开发过程

第 3 页:架构师和Scrum Master的重要性

敏捷开发过程

敏捷开发改进了产品的开发流程,提高了整个团队的效率。下面分析敏捷开发前和敏捷开发后的产品开发的各个阶段。

1) 敏捷开发”前”的产品开发过程

图1 敏捷前开发流程

上图是敏捷开发前我们产品一个版本的开发流程,整个开发大概持续一年左右。从图中可以看出,流程中的大多数活动都是串行进行。这样的一种类似瀑布的开发流程,前提是需求在产品的初始阶段就完整的被捕获并正确的分析,这样才能保证最后交付的产品是客户所需要的产品,但通常这样的理想状况很难实现。

类瀑布的开发流程缺乏灵活性,无法通过开发活动来发现不够确切的需求,导致产品无法随着业务人员和市场的反馈而随需应变,开发出符合业务人员需求的产品。

2) 敏捷开发”后”的产品开发过程

图2 敏捷后开发流程

上图是敏捷开发”后”我们产品一个版本的开发流程,整个开发大概也是持续一年左右,但每个迭代都是1个月时间。和敏捷开发前相比,有很多的区别和优点,下面是其中几点:

市场和需求驱动,拥抱变化

在我们产品敏捷开发中,每个迭代结束,都会有一个产品迭代演示大会,把这个月的开发结果演示给组员、业务人员、售前,甚至客户,并收集反馈。此外,在开发的过程中,产品的业务人员和售前时刻保持与产品开发团队的沟通和工作,保证开发出来的产品是符合业务需求。

充分利用资源和时间

敏捷开发前,产品的需求设计阶段占用整个开发流程35%左右的时间,这段时间只需要几个核心的架构师和设计人员,无法充分地利用开发和测试人员。敏捷开发后,迭代开发、强调沟通、缩减文档,在每个迭代初期就可以充分地利用开发、测试人员的时间,达到效率最大化。

每日交付

产品开发过程中,每天都会做自动化Build,并生成可以交付的产品。业务人员、客户都可以试用并提供反馈和新需求。

充分自动化

敏捷开发强调拥抱变化,这必然带来动荡的产品代码变更。每一个新的功能和修改的功能,都可以影响到其他功能,造成副作用。所以,需要自动化去支持变化,在变化的同时保证质量和开发速度,包括编译自动化、单元测试自动化、功能测试自动化、UI测试自动化、集成测试自动化等。

共3页: 12 3

内容导航

第 1 页:敏捷开发的体会 第 2 页:敏捷开发过程

第 3 页:架构师和Scrum Master的重要性

架构师和Scrum Master的重要性

流程的变化必将带来岗位和职责的变化,架构师和Scrum Master是在敏捷开发中两个重要的人物角色:

1) 产品架构师

在产品的敏捷开发中,特别是我所参与的产品是面向行业的产品,架构师是个举足轻重的角色,需要有深厚的行业背景、创新能力,以及架构能力。

产品是为了解决一类客户需求而存在。但是,客户的需求往往是会随着业务的发展而变化,而且竞争对手也会有类似产品的推出。所以一个产品推出市场后,所具有的功能模块慢慢地会越来越成熟,并拥有越来越多的竞争对手,慢慢地失去竞争力。一个好的产品,特别是面向行业的产品,要具有长期的生命力,需要具有下图所示的产品模型:

图3 产品发展模型

成熟的模块

:指的是推出市场有一段时间,这些功能模块因满足客户的需求而被广泛使用。随着市场趋于稳定,大量竞争对手的产品也推出类似的功能。这些成熟模块都是产品的基本模块,不代表产品的竞争力。产品中如果只具有这些功能模块,随着需求和竞争的激烈,慢慢会走向灭亡。如90年代的BP机一样,当手机一旦推出,这个产品也就走向灭亡。

发展中的模块

:指的是刚推出市场并且具有强劲的市场生命力、符合客户当前几年的业务发展需求,正在被大客户所接受的功能模块。这些功能模块是产品占领市场的动力,是继成熟的功能模块后,产品的新的增长动力。

研究中的下一代产品方向

:指的是还没有推出市场、正在研究中的、符合未来行业五到十年发展方向的模块。当然如果能创造出未来的发展方向,则是最高境界。如任天堂的Wii、苹果公司的iPhone。

一个行业软件产品要保持长期的生命力,在整个产品的生命周期架构规划中,需要考虑到这三种模块和特性,只有这样才能保持产品的先进性和长久生命力。

敏捷开发也强调拥抱市场变化,这对产品架构师提出了很高的要求——深厚的业务背景、创新能力、技术洞察力和架构思想。

2) Scrum Master

ScrumMaster虽然是敏捷开发的新名词,但其工作内容和开发组长没什么太大的区别:安排任务、协调资源、控制进度和解决难题。

架构师根据对行业的理解和创新,设计出产品的架构。ScrumMaster则是进一步分解和实现这个架构中的每个组件。如果形容”奥运会开幕式”是一个产品,架构师则设计整个开幕式的主题、创意、架构和包含的主要环节,而ScrumMaster就是整个庞大工程的详细设计者和协调者。

在我们产品中有三个ScrumMaster,各自负责架构中的不同模块,并和开发人员一起把模块分解成一个个单独的、可以衡量的用例,然后协调开发人员高质量的完成任务。

此外,每天早上需要主持小组成员进行一个10分钟左右Scrum会议。每个组员汇报昨天完成的任务,是否完成任务以及碰到的问题,最后是今天打算完成的任务。ScrumMaster会协调解决每天碰到的问题,确保产品进度和质量。

总结

在笔者的理解中,敏捷开发是一种思维方式和软件过程方法论,以及一系列的最佳实践,它能帮助团队开发出更加符合市场需求的产品。我们的团队在产品两个版本的敏捷开发历程中,不断摸索,找到了一条适合自己的产品敏捷开发流程,我们还将继续用敏捷的思想改进我们的敏捷开发流程,希望能与大家讨论探索,持续改进。

分类: 3电动设备 标签:

关于腾讯敏捷框架TAPD

2011年4月26日 没有评论


腾讯是一家典型的互联网企业,互联网行业有其鲜明的特点:
1.关注用户行为
2.追求创新(腾讯有一个创新中心部门)
3.需求不确定性高
4.快速适应变化
5.快鱼吃慢鱼

腾讯在敏捷开发方面的实践大致包括3个部分:
1.产品
采用FDD,即产品特性开发驱动的一种模式,腾讯的产品会有一个明确的产品经理这样一个角色,他会负责整个产品,包括产品的验证、产品的方向、市场调研、用户调研等。FDD模式是一种非常适合产品经理来对产品做一些滚动的要求,腾讯在产品设计上引入了类似FDD这样的模式,但是也不完全是FDD,只是参考FDD,所有的开发团队都是由产品经理所归纳出来的产品特性去驱动整个产品的研发。

2.项目管理过程:腾讯采取了SCRUM,但也不完全是SCRUM,有腾讯根据自己的特点去总结的一些实践,大概的项目管理过程同SCRUM的过程是比较类似的,包括每天的晨会、迭代、timebox、每个迭代完成的时候会有showcase、回顾总结等。
3.开发实践:参考了很多XP的实践,就XP完整的实践来说会比较理想化,很多东西不一定在实际开发中能够采纳,所以腾讯也是采纳其中的某些实践,比如自动化测试和持续集成,通过这样的实践就能保证产品有一个快速发布的过程。

在腾讯的敏捷实践中,具体的实践情况是这样的:
1.故事墙:就是白板story wall,平时工作中很多团队都会使用,这些团队会把每天开发的一些产品特性采用story的方式每天都在白板里面展示出来,整个团队每天都会围绕这个白板能够清晰的看到整个产品或者整个项目的一个过程,包括整个产品特性的过程。
2.迭代总结:在每一个产品发布的时候都会有一个总结。具体的做法是,把做得好的、不好的总结出来,做得好的在下一次迭代发扬光大,做得不好的在下一次迭代就要注意改进。这样的总结是要求项目的所有成员都必须参加,包括项目的开发人员、测试人员、QA、项目经理、产品经理等,每个人都要去去总结他在上一个迭代中碰到了什么问题,通过便签纸的方式贴出来,项目经理实际上可以看成是SCRUM M a s t e r,包括站起来总结这样一些东西,包括我们下一次迭代继续发扬什么,必须要注意什么东西,最后就会得出一个excel的文档,包括上一个迭代中出的问题,具体的解决办法,都会有。
3.每日晨会:每个团队每天大概花15-30分钟,回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作(特点:是站着开会)。最早是通过白板的方式去做,就是每天项目经理组织团队成员对着白板,白板上体现项目的进展情况,通过会议可以很明确的知道昨天大家做到什么样子,今天大家计划做什么,最早的时候每个成员都是口头汇报的。实践一段时间就发现了一些问题,第一、对于一个20、30人的团队,每天要怎样做晨会,这是目前遇到的比较大的困惑;第二、晨会很容易形式化,究竟带来什么样的效率和效果,目前也在通过一些方式去研究,去探讨。第三、有一些形式上的呆板,刚开始做会觉得比较有意思,觉得这跟传统做法不一样,每天这样做并且做多了就感觉很枯燥,这也是面临一个挑战。后来腾讯也做了一些改进,比如为了让成员的参与程度更强一些,包括形式上会更强一些,现在有些团队就会采取每个人轮流主持的方式,刚开始晨会的时候我们也会通过一些好玩的东西去刺激一下某些东西,但是现在看来的话,感觉改进的还是不是很透。在腾讯内部有一个交流通信的软件,有些项目也开始不采用站起来开晨会的方式,觉得站起来效率也高,就会通过即时通信软件每天去交流,最后由一个人去统一输出,这样能解决一些分布式团队的合作。所谓分布式团队就是这个团队中有些同事在这个大楼,有些同事是在那个大楼,通过这种实时交流的方式可以解决一些问题。
4.结对编程:并没有很好的实施开来,但是在一些团队里面还是一直在尝试着做结对编程的工作。一个在编写程序,旁边还有一个人,同时记录编写过程、编写思路、碰到的问题、自己的想法,编写完以后一段时间他们会交换一下,就是互相交换着进行编程,这是一个结对编程的一个过程。
5.时间盒:timebox,在腾讯的产品研发中,产品的每一个迭代都有一个明确的时间盒。在每一次迭代开始的时候会召开一次IPM会议,即本次迭代的计划会议,会议中团队中的所有成员包括产品人员、开发人员、项目经理、总监、部门领导,一起去敲定本次迭代要完成的任务,一旦任务敲定下来,本次迭代就会严格按照这个去落实执行。
6.一个完整的迭代过程:包括概念、设计、开发、测试和发布五个过程。在概念阶段,会采用FDD里面提到的一些好的最佳实践来支撑到我们怎么样去敏捷的做需求开发,会制定一些产品发布的计划,比如产品在未来,某个迭代什么时候发布,要发布哪些产品特性,都是在这个阶段做的。在设计阶段,会做产品原型上的设计。对于互联网产品说更多的是通过快速原型法快速的让产品在不同范围内去做一些体验,比方产品在某个迭代的一个小迭代里面,可能会在一个团队里面先去体验,可能就会采取发布到公司某一个部门去体验,或者发布到整个公司范围去体验,它会是一个不断放大的一个过程。在开发和测试阶段,更多的采取XP的一些实践,包括编码规范,代码走读,比如1

分类: 3电动设备 标签: ,

CSM(Certified Scrum Master)敏捷总结

2011年4月25日 没有评论

2011年4月14-15日,有幸参加全球敏捷联盟的CSM(Certified Scrum Master)培训,虽然我们在平时工作中一直使用Scrum开发模式,但是对Scrum的理论我还不是十分的清楚,两天全英文的培训使我全面了解了Scrum的基本流程,总结一下培训重点,希望和更多使用Scrum模式的人共同交流探讨,某些术语翻译的不准确,希望批评指正。

1.Scrum简介: Scrum一词来自橄榄球运动,在软件工程中,Scrum是以经验过程为依据,采用迭代、增量的方法来提高产品开发的可预见性并控制风险的理论,Scrum不是一种过程,也不是一项构建产品的技术,而是一个框架,在Scrum框架中可以应用各种过程和技术,Scrum的作用是让开发实践方法的相对功效显现出来以便随时改进。

2.敏捷开发中的Scrum模式:

Scrum是敏捷(Agile)开发的一种实践模式,敏捷开发强调拥抱需求变化,快速响应不断变化的需求,并尽可能快地提供可以工作的软件产品,敏捷最强调的是可以正常工作的软件产品,文档等不是非常的强调(并非不要文档,只是需要必要的文档),敏捷理论认为面对面的沟通交流远比文档更有效。

敏捷开发的Scrum模式是以价值驱动(Value-Driven)的开发模式,即认为用户的需求并不一定需要100%实现,最重要的是将对用户最有价值的功能实现并交付.

敏捷开发中Scrum开发流程如下:

3.Scrum框架元素:

Scrum框架的主要元素有:

(1).3种角色:

a.Scrum Master

b.Scrum团队。

c.产品负责人(Product Owner)

(2).4种会议:

a. Sprint规划会(Sprint Planning Meeting)

b.每日站会(Daily Scrum Meeting)

cSprint评审会(Sprint Review Meeting)

dSprint回顾会(Sprint Retrospective Meeting)

(3).2Backlog列表:

a.产品需求Backlog列表(Product Backlog list)

b.Sprint Backlog列表。

(4).2个燃点图:

a.产品发布燃点图(Product release burndown chart)

b.Sprint燃点图(Sprint buirndown chart)

4.Scrum角色介绍:

(1).Scrum Master:

Scrum Master的主要职责是:

a.排除产品开发和产品负责人之间的障碍,确保产品负责人直接推动开发工作;

b.教授产品负责人如何实现投资回报最大化,以及如何利用Scrum达成目标;

c.激发创造力和放权,从而改善开发团队的环境;

d.千方百计实践和工具,确保每个功能增量都具备潜在可交付行;

e.向各方确保团队工作进展实时更新并高度可视;

(2).Scrum团队:

Scrum团队是Scrum框架的核心,Scrum团队是一个自我管理的组织(Self Organize Team)Scrum团队不需要命令,成员根据自己的兴趣任意选取Sprint Backlog中分解的任务,整个团队为了在Sprint迭代开发周期中提交可工作的软件产品目标而相互合作,Scrum团队的特性:

a.具有不同特长的团队成员,人数控制在5-9个左右。

一个Scrum团队中,开发,测试等人员都需要有,人数不能太多,否则沟通成本太高。

b.确定Sprint目标和具体说明的工作成果。

c.在项目向导范围内有权利做任何事情已确保达到Sprint的目标。

d.高度的自我管理能力。

e.Product Owner演示产品功能。

Scrum团队的成员们必须有这样一个意识:整个团队要么一起成功,要么一起灭亡,没有个体的概念,每个成员只要为了Sprint目标,可以做什么事情。

(3).产品负责人(Product Owner)

产品负责人(PO)负责收集客户需求,并根据产品功能点对用户需求的价值,将客户需求排列优先级形成产品Backlog作为Scrum团队Sprint开发周期的输入。产品负责人的特性如下:

a.确定产品的功能。

b.决定发布的日期和发布内容。

c.根据市场价值确定功能优先级。

Value-Driven,根据功能客户的价值/投资回报率对来确定优先级。

d.Sprint周期内调整功能和调整功能优先级。

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

5. Scrum4种会议介绍:

在介绍Scrum4种会议之前,首先介绍Scrum中一个很重要的概念——Sprint.

Sprint是一个固定时间段的迭代开发周期,一般为2-4周,最长不要超过一个月,Sprint太长风险不易控制,太短则Sprint会议会占用大量时间。一个SprintSprint规划会、每日站会、Sprint评审会和Sprint回顾会组成,Sprint的输入是产品Backlog,输出是包含了Sprint提交的可运行的软件。

(1).Sprint规划会(Sprint Planning Meeting)

Sprint规划会议制定迭代计划,Sprint计划会议的内容包括以下两个部分:

a.产品负责人告诉Scrum团队决定Sprint做什么:

产品负责人把具有最高优先级的产品Backlog呈现给Scrum团队,并一起决定接下来的Sprint中开发什么功能。

b.Scrum团队研究如何实现功能:

Scrum团队根据Sprint规划会议第一部分的产品Backlog,将产品Backlog分解成具体的开发任务,即Sprint Backlog,并估算完成每个任务所需要的大概时间。

这个阶段的会议不要超过4个小时。

(2).每日站会(Daily Scrum Meeting)

一旦Sprint计划阶段结束,2-4周的Sprint就开始了。Scrum Master需要组织团队成员每天开站会. 这个会议是用最多15分钟的时间来让大家过一下scrum的状态。在会上,每个团队成员需要问3个问题:

a.我昨天做了什么.

b.今天做什么.

c.遇到哪些障碍。

谁都可以参加这个会议,但只有Scrum团队成员有发言权。这个会议的目标是得到一个项目的全局观,用于发现任何新的依赖,定位Scrum成员的要求,实时的调整当天开发计划.

注意:每日站会时,只通报进展情况,不做讨论,深入具体的讨论在会议结束之后找时间进行。

(3).Sprint评审会(Sprint Review Meeting)

Sprint结束的时候召开Sprint评审会,这个会议最多不超过4个小时.Scrum团队演示在这个Sprint中开发的产品功能给产品负责人.产品负责人会组织这阶段的会议并且邀请相关的利益相关者参加。业务,市场,技术都要做相关的评审。由产品负责人来决定Product Backlog中的哪些功能已经开发完成 。

(4).Sprint回顾会(Sprint Retrospective Meeting)

Scrum MasterScrum 团队一起回顾当前的Sprint。团队评估大家在一起的工作方式,找出好的方式以后继续发扬,找出需要做的更好的地方,想办法提升。Sprint评审会结束后,新一轮的迭代又继续开始(中间最好修整半天或者隔个周末),迭代会一直继续,直到开发了足够多的功能去交付一个产品。

Sprint回顾会时,汇报经理和产品负责人一般不被邀请参加,主要是为了给Scrum团队一个安全的、畅所欲言的开放环境,毫无顾虑地提出意见帮助Scrum团队更好地工作。

Sprint回顾会时,最好Scrum选择一个好的方面,一个不好的方面讨论,容易在有限时间里充分讨论形成一致意见,并确定责任人执行。

6.ScrumBacklog

Sprint中有两种Backlog:产品BacklogSprint Backlog.

(1).产品Backlog

在产品/项目开始的时候,产品负责人要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog,一个最终会交付给客户的产品特性列表,它们根据商业价值来排列优先级,是Scrum团队每个Sprint的输入。

Scrum团队会根据Product backlog来做工作量的估计。Product backlog应该涵盖所有用来构建满足客户需要的产品特性,包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。

产品Backlog列表中的最小单位为用户故事(User story),用户故事的需要必须独立、可评估大小(用户故事的相对大小),对于用户故事的估计方法如下:

a.选择用户故事大小参照物。

b.Scrum团队使用扑克牌估计用户故事的大小,尽可能意见比较一致或相近。

c.使用菲伯纳西数列:123581321……表示用户故事的相对大小。

d.对于过大的用户故事需要拆分成小的用户故事。

(2).Sprint Backlog

Scrum团队选择并承诺了产品Backlog中要递交的一些高优先级的产品功能点后,这些功能点就会被细化成为Sprint Backlog:一个完成Product Backlog功能点的必需的任务列表.这些点会被细化为更小的任务,工作量小于2天。Sprint backlog完成后,Scrum团队会根据它重新估计工作量,如果这些工作量和原始估计的工作量有较大差异,Scrum团队和产品负责人协商,调整合理得工作量到Sprint中,以确保Sprint的成功实施。

7.2个燃点图:

(1).产品发布燃点图:

产品发布燃点图记录在一段时间内产品Backlog的总剩余估算工作量,估算工作量是以Scrum团队和组织决定的单位为标准,时间是以Sprint为单位。产品发布燃点图是产品剩余工作量趋势图。

(2).Sprint燃点图:

Sprint燃点图展现的是当前Sprint内剩余的Sprint backlog工作量,创建该图需要通过累计Sprint中没人Backlog估算来确定剩余工作量,Sprint内剩余工作量就是所有Sprint Backlog的剩余工作总量,Scrum团队在每日站会过当前Sprint工作状态时,会同步更新Sprint燃点图,时刻显示剩余工作量。用线将图上的点连接起来,团队就可以控制完成Sprint工作的进程,所耗时长并不属于Scrum的关注范围,剩余工作量和完成日期才是利益相关因素。

Sprint燃点图以及Sprint任务分解的重点不是关注是否精确,而是确保Scrum团队可以保持一个稳定的开发速度和产出效率,Scrum团队通过长期对Sprint燃点图的统计分析可以估算出团队的乐观速度,悲观速度和平均速度,在Sprint规划会时可以给出Sprint可以完成的Product Backlog乐观的、悲观的和平均的估计。

8.定义完成(Definition of Done)

Scrum要求团队在每个Sprint内构建可交付的软件产品功能增量,因为对于产品Baclog的功能是否完成每个人的理解可能不同,因此需要定义完成的含义,定义完成由Scrum团队和产品负责人一起讨论决定,只有所完成所规定的工作全部完成时,产品Backlog才算完成,未完成的产品Backlog导入到产品Backlog中,继续下一个Sprint迭代。

 

分类: 3电动设备 标签:

无觅相关文章插件,快速提升流量